On Jun 1, 2:47 am, 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. > > 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?
I hope not. Like many others, I avoid packages the require installation via setuptools. My first experience with setuptools (I do not make much distinction here between setuptools and packages installed using setuptools) was quite unpleasant. It was a couple years ago and I have forgotten a lot of details but it was roughly: Downloaded a package from the net, did the usual "python setup.py install" and got a messages that I needed to install setuptools first. (First time I'd ever heard of setuptools, not idea what it was or did.) Machine not on internet so I looked at readme for other options for installing. No information about dependencies, install, easy_install, setuptools in any of the readme's or other package doc. Finally found a url buried in one of .py files. Eventually, from another machine, I got it downloaded and installed. Ran it, and then the dependency issues popped up with no internet connection, recollection is messages were obscure. Got internet connection and tried again, never did it tell me what it wanted to download or the sizes (internet connection was a modem). Somewhere I got a url for setuptools "help" that pointed the Peak website. I then had to hunt around for a long time before finding the setuptools docs. When I did find them they appeared to be written for a packaging programmer, not for an someone who just want to get a package installed so he could continue with his main task. The kicker was that after all of this BS, I discovered that I could install the package simply by copying it's files to the Python install site-lib directory! Sheesh!! I have since used setuptools a few more times and had problems several times. Now, my complaint about setuptools is not any of the specific problems I've had using it -- those presumably could be (perhaps have been) fixed. The problem is the disconnect between what I see as blatantly obvious requirements for any kind of installer and what setuptools provides. I consider the need for locally available usage instructions so obvious as to not needing mentioning. I consider sensible behavior in the face of no, slow, or bad internet connections obvious. I consider defaults (not auto-downloading potentially large files) to be obvious. That the the setuptools developers do not share my world view makes me unable to trust them. Perhaps they will silently change some settings on my machine that I depend on? Setuptools' philosophy seems to me to be fundamentally Microsoftian: sit back, relax, we'll take care of everything (which requires you to effectively give your machine to us, but please don't worry about that.) It is a philosophy I detest, and use free software to get away from. > (2) What bugs you most about the current featureset? > > (3) Which features do you need the most (list in order of need)? If must *work*, always. It must have simple, very well written docs, that are always easily accessible. Nobody should be expected to become a setuptools expert in order to install a package, but if they need to do something out of the ordinary, they must be able to find out how, quickly and effectively. It must work reliably and simply in a wide variety of environments, not just the enviroments the developers happen to be used to (no, slow, intermittent internet, unusual install locations, multiple package versions, multiple python versions, different compilation environments...) It's scope should be limited to Python. There are OS packaging tools for applications (python or otherwise), and the ongoing problems with them (c.f. Fedora's rpm/yum) despite a decade of work make me doubtful a python centric project that tried to tackle the problem could get it right. Need to be able to *manage* packages (remove, list, maintain info about,...) as well as install them. A common way of packaging / installing documentation. Most of my Python work in on Windows and whenever I install a Python package (setuptools or otherwise), I have to look for a sepreate docs package, and if not exist, download the source package, find the docs in it, sometimes build them, and if I can't to that, try to wget the online docs. Would like a nerw setuptools to provide the machinery and conventions to allow packager to easily include docs in a package and have them installed in a common, indexed, location on the target machine. (C.f. Activestate's Perl.) > (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? -- http://mail.python.org/mailman/listinfo/python-list
