On 1 Jun, 10:47, Alia Khouri <[EMAIL PROTECTED]> wrote: > Can we open up the discussion here about how to improve setuptools > which has become the de facto standard for distributing / installing > python software. I've been playing around with ruby's gems which seems > to be more more mature and usable.
I'm sure people also regard Perl's CPAN-related tools and infrastructure to be more mature and usable, but I'd like to widen the discussion beyond language-specific package and dependency management. > From my perspective, the relative immaturity of setuptools and its > simultaneous widespread use is a clear python weakness and can make > python less easy to absorb than it should be. > > A few questions (please add more) so far are: > > (1) Should setuptools be standard? > > (2) What bugs you most about the current featureset? > > (3) Which features do you need the most (list in order of need)? I'm not really in your target audience for these questions since I never use setuptools: instead, I use the Debian-based package and dependency management provided by my system. If any of the system packages use setuptools, it's to build packages in such a way that they resemble classic distutils package installations. However, I do work in environments where I do have to install packages to non-system locations manually. Even in such situations, the packages I tend to use employ a plain distutils-based setup script, and I'm not completely sure that I'd want to use setuptools/ easy_install, since aside from some dependency management (which I doubt extends to various non-Python libraries) it doesn't provide compelling advantages over distutils like uninstallation, for example. > (4) Shouldn't we just port gems to python? > > (5) What's the best community process to improve setuptools? > > (6) What's your ideal conception of the 'standard python package > manager? Well, I don't deny the utility of a Python package manager given that it could be useful for people who use systems which don't provide system package/dependency management (at least in a consistent or widely-deployed fashion) or who have to work without taking advantage of system packages (whether it be due to privileges or issues with decisions taken by the package maintainers), but the most important thing from my perspective is that it should complement and co-operate with system packaging activities. Although distutils is often derided for its architecture and for some odd usability issues, it does take away a lot of the tedious work required when laying out installations for subsequent packaging. Perhaps efforts should be directed towards the distutils type of work, making it easier to install things like documentation and non-code resources, potentially even employing a different architecture: once upon a time, Python libraries were installed using a Makefile-based scheme, and there are plenty of Makefile-like tools and libraries written in Python [1]. In addition, there should be efforts which integrate this packaging with the existing range of package and dependency managers: it shouldn't be the case that one only considers a Python-only dependency manager, because that just leads to the usual reinvention of what has been done before, plus those people packaging for Debian, Fedora, *BSD and so on won't see any benefit from what has been done. Indeed, it shouldn't be inconceivable that a Python-only dependency management solution might be based on existing tools and infrastructure, rather than trying to figure out issues like reliability and redundancy all over again. I note that the overlap between various mature projects of this nature and the distutils community seems to be minimal. Once again, I suggest that people take advantage of the expertise and experience built up in other projects and communities, and not merely those whose products conveniently resemble a preconceived notion of what such a solution should be in the Python world. CPAN and friends and all their baggage are not universally applicable, and any consideration merely of such solutions will produce a setuptools successor whose relevance is just as limited as its predecessor. Paul [1] http://wiki.python.org/moin/ConfigurationAndBuildTools -- http://mail.python.org/mailman/listinfo/python-list
