I would suggest there may be three use cases for Python installation tools. Bonus -- I'm not a web developer! :) Case One: Developer wishing to install additional functionality into the system Python interpreter forever Case Two: Developer wishing to install additional functionality into the system Python interpreter for a specific task Case Three: Person wanting to install an application which happens to be written in Python
The prime limitation of setuptools appears to me to come when there are conflicts. Other than that, for packages where it is available, I have never had an issue with the functioning of setuptools. It's Just Fine. For issues where there are conflicts, where I have been sufficiently motivated, setting up a virtualenv has more than met my needs. In fact, that's and *awesome* piece of functionality. For case one, where I want to install additional functionality into my system Python interpreter "forever", it would be great to have my system manage this. On my ubuntu machine, this happens. The Ubuntu packages take care of things very satisfactorily and I don't see how anyone would have a problem with it. I don't know what the situation is under Windows, however systems such as the Enthought Python Suite do provide kitchen-sink-included Python distributions. Perhaps an automated updates site could be configured such that there was a package for a variety of "Python + some extra modules" scenarios. For installing applications, I would presume that app developers would generally take care of this themselves, through the use of an MSI or .deb file in order to protect their dependencies somewhat. For anyone looking to extend their interpreter for some specific task, virtualenv and setuptools should do the job, and the developer can just go the extra mile to do the work to get it right themselves. Perhaps the most under-served use case is people who want a kitchen-sink-included distribution, to be managed by their system packages. Either they are not away of systems such as EPS or are opposed to it in principle. Were time and effort no obstacle, I would suggest that it may be worth Python.org offering to host and/or maintain a variety of Python distributions available for installation which include various standard extensions. The model that eclipse takes, with a "base" system and plugins, but with flavoured versions available (i.e. Scientic Python Distribution to include SciPy, Numpy and MatPlotLib for example). Thoughts? On Thu, Mar 26, 2009 at 9:56 AM, Ben Finney < bignose+hates-s...@benfinney.id.au <bignose%2bhates-s...@benfinney.id.au>>wrote: > Paul Moore <p.f.mo...@gmail.com> writes: > > > If you would, I'd appreciate it. Sometimes I feel that the > > distutils/setuptools discussions need better input from the > > non-web-developer community. And even more so from the "not a > > developer, just a user" community! > > And the often-obscured community: those who desperately want the > Python stuff to just behave the same way everything else on their > system does, i.e. be managed approrpiately by the operating system > package manager. A Python-specific packaging system which makes it > harder to fit Python packages into a broader OS policy works very much > at odds with that. > > However, I, too, am on a different continent from the conference. > > -- > \ “Kill myself? Killing myself is the last thing I'd ever do.” | > `\ —Homer, _The Simpsons_ | > _o__) | > Ben Finney > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/tleeuwenburg%40gmail.com > -- -------------------------------------------------- Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think"
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
