Re: [Distutils] pip vs easy_install vs distutils2
2010/5/29 P.J. Eby
At 01:13 AM 5/29/2010 +0200, Tarek Ziadé wrote:
The problem I have with this approach is that we need to manage somewhere at PyPI a list of potential installers, and maybe deal with upgrades and replacements. Plus, I am not sure that a user will really understand what to do when he's asked to chose an installer. Sounds like something we should only ask to power users, and people that know what they are doing with p7g. So a bootstrap script is useless for them.
Actually, the way it would (presumably) work would be just a script like Guido's that downloads a source archive from PyPI and runs setup.py install. So, it's not really a matter of "choosing" an installer -- it'd just be, "download and install a package from source".
If the package itself needs one of those other things in order to build itself or install dependencies, then the next stage of bootstrap is its problem (e.g. via ez_setup), not the stdlib's.
So, I don't see the "power users only" objection making sense, at least if we drop back to what I believe was Guido's original proposal for a bootstrap script a few years ago.
I was not thinking about this proposal. If this what Guido proposed at the summit, then I misunderstood. I was thiking about a bootstrap process on the end-user side, to set up an installer once for all, on a fresh Python. The problem with the feature you describe (bootstrap embed in the archive itself) is that we imply that the packager chooses himself an installer and forces the end-user to use it when he installs the software. This means that the end user might end up with several installers installed for the same Python. It also implies that the developer provides a smart setup.py script that embeds that bootstrap, and runs some code. I think separating the concerns and letting the end user pick/use explicitly *one* installer globally is better because several installers won't compete on the target system (even if we supposely want them all to be compatible in the future). Of course, this is only true for source distributions. It will also allow distributions to be "dumb" envelopes with static metadata that are the same all the time, no matter which tool created them, and eventually remove setup.py in favor of statically described metadata using PEP 345. Today, for instance, if an installer wants to install a distribution based on setuptools, it has to run the "egg_info" command to extract the metadata, on the target system. Being able to get those metadata without running any code would be better. For instance, installers could list all dependencies for a project by querying PyPI with zero download/execution. (thanks to PEP 345 environment markers) What would make more sense I think, would be to have all installers an identical archive for a given project, that doesn't need more code to be run to get all the metadata. So at the end, the end user would chose an installer that is compatible with these archive, and know how to install them. In other words, have ez_setup for example, run once for all at the Python level, and be THE installer. Or run a pip_setup or whatever. Regards, Tarek -- Tarek Ziadé | http://ziade.org
On Sat, May 29, 2010 at 10:19 AM, Tarek Ziadé
It will also allow distributions to be "dumb" envelopes with static metadata that are the same all the time, no matter which tool created them, and eventually remove setup.py in favor of statically described metadata using PEP 345.
+ statically described distribution content
On May 29, 2010, at 10:19 AM, Tarek Ziadé wrote:
I think separating the concerns and letting the end user pick/use explicitly *one* installer globally is better because several installers won't compete on the target system (even if we supposely want them all to be compatible in the future). Of course, this is only true for source distributions.
It will also allow distributions to be "dumb" envelopes with static metadata that are the same all the time, no matter which tool created them, and eventually remove setup.py in favor of statically described metadata using PEP 345.
Today, for instance, if an installer wants to install a distribution based on setuptools, it has to run the "egg_info" command to extract the metadata, on the target system. Being able to get those metadata without running any code would be better. For instance, installers could list all dependencies for a project by querying PyPI with zero download/execution. (thanks to PEP 345 environment markers)
What would make more sense I think, would be to have all installers an identical archive for a given project, that doesn't need more code to be run to get all the metadata.
So at the end, the end user would chose an installer that is compatible with these archive, and know how to install them. In other words, have ez_setup for example, run once for all at the Python level, and be THE installer. Or run a pip_setup or whatever.
How would OS vendors get into the game? I could imagine that Ubuntu would want to make an opinionated choice for our users, and maybe even set things up so that packages are installed from our archives (as .deb packages) by default. This would make things very easy for the majority of users, though of course we'd have to allow experts to customize it to grab from the Cheeseshop or use a different installer. -Barry
On Thu, Jun 3, 2010 at 8:38 AM, Barry Warsaw
So at the end, the end user would chose an installer that is compatible with these archive, and know how to install them. In other words, have ez_setup for example, run once for all at the Python level, and be THE installer. Or run a pip_setup or whatever.
How would OS vendors get into the game? I could imagine that Ubuntu would want to make an opinionated choice for our users, and maybe even set things up so that packages are installed from our archives (as .deb packages) by default. This would make things very easy for the majority of users, though of course we'd have to allow experts to customize it to grab from the Cheeseshop or use a different installer.
I could see how a deb might make sense for an unqualified installation, i.e., one where no specific version or location is indicated. *Probably* a specific version would be okay, but the way deb archives work it seems like the archive would usually be unable to satisfy the request. It would be interesting if you could also hook into a deb generation script, and install ad hoc packages as debs. This really isn't a system choice, but a where-the-package-is-installed choice. If installing in /usr/lib/* then using the system package makes sense. If installing anywhere else it doesn't make sense (home directory, virtualenv environment, something ad hoc using install options). I wonder if it would work best to control this through some distutils.cfg-like file (distutils.cfg is terrible though), that would be looked up based on the installation location. -- Ian Bicking | http://blog.ianbicking.org
On 4 Jun 2010, at 20:07, Ian Bicking wrote: SuSE sponsored the opensuse build server for that purpose: providing a build server insulated from the developers environment. https://build.opensuse.org/ They provide yum/yast repositories so binaries can be downloaded automatically (like in the easy_xxx style). I have done some work with it in the recent past if somebody is interested: http://pyvm.sf.net Regards, Antonio Cavallo
On Thu, Jun 3, 2010 at 8:38 AM, Barry Warsaw
wrote: So at the end, the end user would chose an installer that is compatible with these archive, and know how to install them. In other words, have ez_setup for example, run once for all at the Python level, and be THE installer. Or run a pip_setup or whatever.
How would OS vendors get into the game? I could imagine that Ubuntu would want to make an opinionated choice for our users, and maybe even set things up so that packages are installed from our archives (as .deb packages) by default. This would make things very easy for the majority of users, though of course we'd have to allow experts to customize it to grab from the Cheeseshop or use a different installer.
I could see how a deb might make sense for an unqualified installation, i.e., one where no specific version or location is indicated. *Probably* a specific version would be okay, but the way deb archives work it seems like the archive would usually be unable to satisfy the request. It would be interesting if you could also hook into a deb generation script, and install ad hoc packages as debs.
This really isn't a system choice, but a where-the-package-is-installed choice. If installing in /usr/lib/* then using the system package makes sense. If installing anywhere else it doesn't make sense (home directory, virtualenv environment, something ad hoc using install options). I wonder if it would work best to control this through some distutils.cfg-like file (distutils.cfg is terrible though), that would be looked up based on the installation location.
-- Ian Bicking | http://blog.ianbicking.org _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
On Jun 04, 2010, at 01:07 PM, Ian Bicking wrote:
On Thu, Jun 3, 2010 at 8:38 AM, Barry Warsaw
wrote: So at the end, the end user would chose an installer that is compatible with these archive, and know how to install them. In other words, have ez_setup for example, run once for all at the Python level, and be THE installer. Or run a pip_setup or whatever.
How would OS vendors get into the game? I could imagine that Ubuntu would want to make an opinionated choice for our users, and maybe even set things up so that packages are installed from our archives (as .deb packages) by default. This would make things very easy for the majority of users, though of course we'd have to allow experts to customize it to grab from the Cheeseshop or use a different installer.
I could see how a deb might make sense for an unqualified installation, i.e., one where no specific version or location is indicated. *Probably* a specific version would be okay, but the way deb archives work it seems like the archive would usually be unable to satisfy the request.
That seems about right.
It would be interesting if you could also hook into a deb generation script, and install ad hoc packages as debs.
I have evil plans... :)
This really isn't a system choice, but a where-the-package-is-installed choice. If installing in /usr/lib/* then using the system package makes sense. If installing anywhere else it doesn't make sense (home directory, virtualenv environment, something ad hoc using install options). I wonder if it would work best to control this through some distutils.cfg-like file (distutils.cfg is terrible though), that would be looked up based on the installation location.
I'd agree. There's definitely a difference between *development* and *deployment*. When I'm developing some library or app, I'm living in my own little world of virtualenv or something similar. I definitely do not want any of that to influence my system Python, at least for the package under development. It's possible that I'll want some of the dependencies installed in my system Python, but then only the ones blessed by my OS, or at least that play my OS package manager's games properly (e.g. an on-demand spun .deb). -Barry
participants (4)
-
Antonio Cavallo
-
Barry Warsaw
-
Ian Bicking
-
Tarek Ziadé