2009/3/25 Tennessee Leeuwenburg <tleeuwenb...@gmail.com>: > 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
If none of these includes managing packages (... similar to apt, yum, and equivalent ;) pls include it ... and I mean it from a higher level of abstraction; i.e. disregarding the nature of the «thing» (pkg, mdl, web framew, plugin, console app, GUI, sci-tool, and so on ... made with Py ;) > The prime limitation of setuptools appears to me to come when there are > conflicts. IMO the prime limitation of setuptools (for installing pkgs ... and so on ..) appears to me when I want to control what I've installed (... a broader situation, i.e. it includes the specific case when there are conflicts ... and many others ... like removal, etc ... ). > For issues > where there are conflicts, where I have been sufficiently motivated, setting > up a virtualenv has more than met my needs. I dont think this should be *THE* option ... > In fact, that's and *awesome* > piece of functionality. But shouldnt be the only one ... not everybody (... devs & users ...) will be open to setup a virtual env in order to install a Py app ... even myself ... I'd do it if I really need it ... else it is just painful and non-sense to force me to do it ... and I dont think it'd be right either ... > 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. Well I do ... my example is as follows (... it actually happened few days ago ...) : - I maintain many Trac instances in many different places ... - I updated some of them to Trac 0.11.1 ... - One of these was a host running Ubuntu Hardy ... and AFAIK there are no official debs for Ubuntu Hardy, including backports ... but only for Intrepid ;) - So I removed Trac 0.10 and installed Trac 0.11, this time using setup.py since I didnt have stdeb (... or equivalent ;) at hand ... - Few months later there was a problem with that server ... - Since I'm used to use apt+dpkg I didnt find Trac among the list of installed soft and I completely forgot about all the previous steps (... believe me my memory sucjks ... :S ...), I though Trac was removed and I installed trac 0.10 once again from a local repo ... - Results ... conflicts everywehere and time spent in finding out what was wrong ... Besides I hosted multiple Trac instances in that single machine (... that's why I package plugins as egg files ... most of the time I face this situation, and I always try to do it as portable as possible to decrease maintainance effort ... ;) - ... and the solution was to remove trac (pkg & egg) folder, and this is ugly (... at least these days in XXI century ... and me thinking in taking control over the whole Emperor Vader's fleet ... I want all their spaceships and vessels ... ;) but ... what if the installation includes some other files placed somewhere else ... they remain there and they'r useless ... and you possibly wont ever know they'r still there ... if you dont use apt or similar ... ;) > Perhaps an automated updates site could be configured such that there was a > package for a variety of "Python + some extra modules" scenarios. AFAIK PyPI offers some kwalitee (cheesecake) metrics and this includes installability ... perhaps these metrics could be extended to consider whether it is possible or not to automatically build packages for a particular platform (debs, rpms, win_inst), and ... as a side-effect, additional service or maybe because of the devs manually uploading the «platform-specific pkgs» ... include those packages in PyPI ... (no debs allowed in there ... yet ;) Perhaps I'm going too far up to this point ... and I'm just dreaming ... but, beyond all these ... perhaps easy_install could just be a little bit smarter and do things as follows : 1 - Detect the platform of the target host (i.e. the OS | distro in the «machine» where the app | framework | ... will be installed ) 2 - Find out if there is a specific install package for this OS | distro in PyPI ( ... or the downloads site ...) 3 - Install the specific install package ... 4 - If either 2 or 3 goes wrong ... fall-back to installing the source distro as usual (... perhaps notifying «the user» of what's going on and asking him about whether to proceed or not ...) Doing nothing but this (... and allowing to upload debs to PyPI, together with including (b|s)dist commands for debs ... in order to get the sdist and build my own DEBs in case I cant find one ... just like I'd do it today using distutils RPM support ... ;) I'd be the happiest man in the world ... maybe some others will be that happy too ... ;) PS: «Random ideas» ... ;) -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: _______________________________________________ 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
