On 7 December 2015 at 16:21, Erik Bray <erik.m.b...@gmail.com> wrote: > Exactly--as both a library developer / maintainer and system > integrator I would find such a flag very useful (especially since I > can just set it in a config file and forget it). It would be right > for me. But wouldn't break anything for anyone else. > > Ironically, the default behavior of `setup.py install`, on projects > that use setuptools, is to install an egg directory which is > *definitely* not for everybody, especially not anymore. That's why > --single-version-externally-managed exists. A --pip flag would be > very much like --single-version-externally-managed (sort of a > specialized extension of it) that also includes "do everything pip > does" which includes installing dependencies and copying > .egg-info/.dist-info to the appropriate location, which is what I want > to replace all instances of `setup.py install` with. That includes > users running `setup.py install`, who have a hard enough time as it is > keeping up with Python build/installation "best practices" as it is.
One thing that bothers me about this proposal. If someone does "pip install --no-binary" for your package, and you have the "--pip" flag in your setup.cfg, pip will use "setup.py install" to do the install. Which, if I understand this proposal correctly, will attempt to "fall back" to pip because "--pip" is in setup.cfg. Which results in an infinite loop of pip and setup.py invoking each other. I'm not sure how pip could detect a situation like this, so there's a risk of some *very* obscure corner cases, which I'm sure people will end up hitting. As a user level command line flag, "setup.py install --pip" isn't much better than "pip install ." As a project config, we get the issue noted above, and the user has to edit the project code to fix it. As a per-user or global config, we get the issue above, but we could reasonably say it's the user's mistake and the user has the means to fix it. But it's still not a great UX. It's quite possible I'm missing something here (at a minimum, I'm making huge assumptions about how the feature would be implemented) but I think the behaviour needs to be thought through in a bit more detail. Paul _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
