[Python-Dev] "setuptools has divided the Python community"

[Olemis Lang]

2009/3/25 Tennessee Leeuwenburg <tleeuwenburg at 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: