Mailman 3 July 2009 - Distutils-SIG

Re: [Distutils] [Python-Dev] PEP 376 - from PyPM's point of view
by P.J. Eby July 15, 2009

July 15, 2009

At 06:40 PM 7/15/2009 +0100, Paul Moore wrote: >And of course, someone has to do the clean-up. It seems to me that the >fact that people are more inclined to reinvent the code than to try to >understand the existing codebase and pick out the relevant bits, says >something important about how easy it would be to maintain the >existing code within the Python core... That's normal for any code that contains "legacy" issues, which is why people always prefer rewriting code they don't understand: it's more fun to write than to read. However, as Joel Spolsky has well explained, rewriting such code inevitably means that you must re-learn the lessons that were learned by the original author. It seems like a waste, but then, I suppose those lessons must be relearned *some* way. I just think it'd be better if, having re-learned most of the lessons by trying to rewrite, one could then go back and learn the rest from the code. ;-) That having been said, it's obviously a dead parrot... one which I will now cease attempting to revive.

1 0

Re: [Distutils] [Python-Dev] PEP 376 - from PyPM's point of view
by P.J. Eby July 15, 2009

July 15, 2009

At 07:07 PM 7/15/2009 +0200, Tarek Ziadé wrote: > Part of the rejection of setuptools is because of that and > because you don't > bless anyone to maintain the project code base, or do releases, >neither to communicate clearly > on what's its roadmap. Jim Fulton and Ian Bicking have been officially blessed for *years*, and I've posted plenty about what's on its roadmap. >I really don't understand why you keep on pushing setuptools *code* pkg_resources is not setuptools; its stability and revision history are very different, as it addresses different problems.

1 0

debian packaging
by Rakotomandimby Mihamina July 15, 2009

July 15, 2009

Hi all. As you probably know: http://www.mail-archive.com/debian-python@lists.debian.org/msg05456.html I would like to unofficially package Plone 3.3+ for Debian. Unofficially, because I would like to package from the buildout/egg. That way, it will never comply with the Debian policy. Good idea? Bad idea? Will some help?...

1 0

Re: [Distutils] [Python-Dev] PEP 376 - from PyPM's point of view
by P.J. Eby July 15, 2009

July 15, 2009

At 11:10 AM 7/15/2009 +0100, Paul Moore wrote: >I propose that before the current prototype is turned into a final >(spec and) implementation, the PEP 302 extensions are extracted and >documented as an independent protocol, purely part of PEP 376. (This >*helps* implementers, as they can write support for, for example, >eggs, without needing to modify the existing egg importer). Btw, this is why setuptools chose to implement these things as adapters or generic functions in pkg_resources (and in the vestigial bits that were added to python 2.5's pkgutil). So as you can see, trying to solve these particular problems tends to lead to reinventing setuptools or at least portions thereof. ;-) >But the >problem is that too many people dislike setuptools as it stands for it >to gain support. My understanding is that the current set of PEPs were >intended to be a stripped down, more generally acceptable subset of >setuptools. Let's keep them that way (and omit the complexities of >multi-version support). Even without multi-version support, the parts of PEP 376 that aren't about uninstallation are still reinventing chunks of pkg_resources. Had pkg_resources been in the stdlib a couple years back (note that bugs and changes in it are still quite rare), the PEP 376 bits for pkgutil could have been focused strictly on uninstallation, and just reused pkg_resources API for finding distributions, reading metadata, getting version info, etc. etc. All that stuff is extremely stable code, very widely used for a very long time. If politics is the only thing keeping it from being used, then that's a pretty sad statement about the community, given that pkg_resources is not to blame for 99% of what people complain about in relation to setuptools. All pkg_resources does is find stuff (on request) and maybe add it to sys.path (on request), pull out data and metadata from distributions (on request), or set up namespace packages (on request). So if politics demands that it be rejected by association with "setuptools", then just search-and-replace the API, PEP 8-ify it, call it something different, and lie to everyone about where it came from. I won't tell if you won't. ;-)

3 2

Re: [Distutils] [Python-Dev] PEP 376 - from PyPM's point of view
by P.J. Eby July 15, 2009

July 15, 2009

At 04:14 PM 7/15/2009 +0100, Paul Moore wrote: >Look - I really, really don't mind if people use setuptools. Honest. >But I do mind if core python gets changed to support little bits of >what setuptools does, adding complexity to deal with issues that >setuptools handles, but without making it possible to avoid using >setuptools. I don't see how that's being proposed. Nothing in PEP 376 requires setuptools or any portion thereof, AFAICT.

1 0

Not installing the install_requires
by Peter Bengtsson July 15, 2009

July 15, 2009

I've just made a package http://pypi.python.org/pypi/premailer To figure out if I've got it right I've tried installing it like this:: $ cd /tmp $ mkvirtualenv --no-site-packages test_premailer $ easy_install premailer Searching for premailer Reading http://pypi.python.org/simple/premailer/ Page at http://pypi.python.org/simple/premailer/ links to .py file(s) without version info; an index scan is required. Scanning index of all packages (this may take a while) Reading http://pypi.python.org/simple/ Reading http://www.peterbe.com/plog/premailer.py Best match: premailer 1.0 Downloading http://pypi.python.org/packages/source/p/premailer/premailer-1.0.tar.gz#md5… Processing premailer-1.0.tar.gz Running premailer-1.0/setup.py -q bdist_egg --dist-dir /tmp/ easy_install-R730U5/premailer-1.0/egg-dist-tmp-epbGlW Traceback (most recent call last): File "/home/peterbe/virtualenvs/test_premailer/bin/easy_install", line 8, in <module> load_entry_point('setuptools==0.6c9', 'console_scripts', 'easy_install')() File "/home/peterbe/virtualenvs/test_premailer/lib/python2.5/site- packages/setuptools-0.6c9-py2.5.egg/setuptools/command/ easy_install.py", line 1671, in main File "/home/peterbe/virtualenvs/test_premailer/lib/python2.5/site- packages/setuptools-0.6c9-py2.5.egg/setuptools/command/ easy_install.py", line 1659, in with_ei_usage File "/home/peterbe/virtualenvs/test_premailer/lib/python2.5/site- packages/setuptools-0.6c9-py2.5.egg/setuptools/command/ easy_install.py", line 1675, in <lambda> File "/usr/lib/python2.5/distutils/core.py", line 151, in setup dist.run_commands() File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands self.run_command(cmd) File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/home/peterbe/virtualenvs/test_premailer/lib/python2.5/site- packages/setuptools-0.6c9-py2.5.egg/setuptools/command/ easy_install.py", line 211, in run File "/home/peterbe/virtualenvs/test_premailer/lib/python2.5/site- packages/setuptools-0.6c9-py2.5.egg/setuptools/command/ easy_install.py", line 446, in easy_install File "/home/peterbe/virtualenvs/test_premailer/lib/python2.5/site- packages/setuptools-0.6c9-py2.5.egg/setuptools/command/ easy_install.py", line 476, in install_item File "/home/peterbe/virtualenvs/test_premailer/lib/python2.5/site- packages/setuptools-0.6c9-py2.5.egg/setuptools/command/ easy_install.py", line 655, in install_eggs File "/home/peterbe/virtualenvs/test_premailer/lib/python2.5/site- packages/setuptools-0.6c9-py2.5.egg/setuptools/command/ easy_install.py", line 930, in build_and_install File "/home/peterbe/virtualenvs/test_premailer/lib/python2.5/site- packages/setuptools-0.6c9-py2.5.egg/setuptools/command/ easy_install.py", line 919, in run_setup File "/home/peterbe/virtualenvs/test_premailer/lib/python2.5/site- packages/setuptools-0.6c9-py2.5.egg/setuptools/sandbox.py", line 27, in run_setup File "/home/peterbe/virtualenvs/test_premailer/lib/python2.5/site- packages/setuptools-0.6c9-py2.5.egg/setuptools/sandbox.py", line 63, in run File "/home/peterbe/virtualenvs/test_premailer/lib/python2.5/site- packages/setuptools-0.6c9-py2.5.egg/setuptools/sandbox.py", line 29, in <lambda> File "setup.py", line 4, in <module> File "/tmp/easy_install-R730U5/premailer-1.0/premailer/__init__.py", line 1, in <module> File "/tmp/easy_install-R730U5/premailer-1.0/premailer/ premailer.py", line 5, in <module> ImportError: No module named lxml.html The setup.py (see http://github.com/peterbe/premailer/tree/master) contains the following: install_requires=[ 'lxml', ], Why does easy_install not try to install lxml before it installs the package?

2 3

[issue80] sys.path corruption in pkg_resource.py
by raybaut July 15, 2009

July 15, 2009

New submission from raybaut <pierre.raybaut(a)gmail.com>: Tested on Windows XP with setuptools 0.6c9: 1. Open a Python intepreter in "C:\Python25\Lib\site-packages": a) run cmd.exe b) change directory to "C:\Python25\Lib\site-packages" c) run python.exe 2. type "from pkg_resources import resource_stream" 3. type "import sys; sys.path" -> you will see that "C:\Python25\Lib\site-packages" has been removed from sys.path The "C:\Python25\Lib\site-packages" sys.path entry is removed abusively by "C:\Python25\lib\site-packages\pkg_resources.py", at line 2250, in insert_on: del npath[np], path[np]. The reason is that, in interactive mode, the first entry of sys.path is '' - and pkg_resources.py replace it by "C:\Python25\Lib\site-packages" at line 2228: npath= map(_normalize_cached, path) ...and then considers it as a replicate to be removed at line 2250. ---------- messages: 327 nosy: raybaut priority: bug status: unread title: sys.path corruption in pkg_resource.py _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue80> _______________________________________________

1 0

mr.developer: share checkouts between buildouts
by Ross Patterson July 15, 2009

July 15, 2009

I often end up doing development on the same distribution for multiple projects and have long wished for a simple way to share the same clone/checkout between these multiple buildouts. What would you think about supporting a shared sources directory much in the same vein of zc.buildout's use of eggs-directory, zc.recipe.cmmi's use of download-cache, and plone.recipe.zope2install's use of zope-directory all of which can be set in the users ~/.buildout/default.cfg? If the option is set, we could do the clone/checkout into the shared sources directory and then symlink them into sources-dir. Thoughts? Ross

2 1

"setup.py needs to go away" (was [PEP 376] - Open questions on python-dev)
by David Cournapeau July 14, 2009

July 14, 2009

I am moving this discussion out of python-dev, as it is outside the thread topic, but an important discussion nonetheless: 2009/7/9 Eric Smith <eric(a)trueblade.com <mailto:eric@trueblade.com>>: > P.J. Eby wrote: >>> >>> ISTM that the problem that it solves is uninstall in the absence of >>> the original installer. >> >> Or uninstall where the installer is "setup.py install", actually. > > I think we need to move away from "setup.py install". It's the antithesis of > static metadata. setup.py needs to go away. > > If we have a static metadata file called, say "setup.info <http://setup.info>", then I'd like to > see: > "bdist_rpm setup.info <http://setup.info>" produce a .rpm > "bdist_msi setup.info <http://setup.info>" produce a .msi > "bdist_deb setup.info <http://setup.info>" produce a .deb > "bdist_egg setup.info <http://setup.info>" produce a .egg > and so on. > > There might be a library (and I call dibs on the name "distlib" :) that > provides support routines to parse setup.info <http://setup.info>, but there's no framework > involved. And no need for a plugin system. I too would like to see this kind of system, and have been thinking quite a bit about it. Looks like I am not the only one. P.J. Eby mentioned that designing such a thing by comity is not likely to work well. But I think we can inspire ourselves from existing designs. One such system is the haskell build system, cabal: http://www.haskell.org/cabal/release/cabal-latest/doc/users-guide/ Among other things: - It is based on a mostly static file, parsed by the cabal package. - Installation of 'libraries' (equivalent of our modules and packages) and executables (scripts) is covered. - Debug and normal build for compiled extensions is handled, metadata as well. Simple conditional for different platforms support. - Optional haskell code ala setup.py can be executed for the complicated cases. - optional integration with source control systems - it has command lines option compatible with autotools -> FHS-compliant packages would be easier as well. - cabal is integrated with a db of packages, to form hackage: it handles installations, dependency handling (but not uninstallation it seems). I don't have much experience with this part of the design, though. I think it is a good and strong baseline as a starting point. Reusing this design in a python equivalent should be much easier than starting a system from scratch. Under this scheme, backward compatibility with distutils could be attempted by automatically converting setup.py files to this system, and vice et versa. The development could be gradual, reusing some parts of distutils during the development phase. My own motivation comes from my experience in maintaining and 'improving' distutils extensions used in numpy and scipy. I have a pretty good idea of the flaws and internals of distutils, and care about every platform that numpy supports (that is most if not all the ones supported by python). cheers, David

7 19

Re: [Distutils] [Python-Dev] PEP 376 - Open questions
by Sridhar Ratnakumar July 13, 2009

July 13, 2009

On Thu, 09 Jul 2009 01:22:19 -0700, Tarek Ziadé <ziade.tarek(a)gmail.com> wrote: > On Thu, Jul 9, 2009 at 3:42 AM, Sridhar > Ratnakumar<SridharR(a)activestate.com> wrote: >> Other than easy_install/pip, there is also PyPM which is being >> developed at >> ActiveState. PyPM is the Python package manager much like what ppm is >> for >> ActivePerl. >> > > Great ! besides the RECORD file, anything remark on the PEP from a > PyPM point of view ? I'll shortly send an email I composed regarding this. > Once Paul has finished to work on the PEP 302 part of the prototype, > maybe we could try it out > on PyPM to see how it fits ? I took a look at PEP 302 and Paul's new implemention in pkgutil2.py http://bitbucket.org/tarek/pep376/src/tip/pkgutil2.py And yes, I'd happy to try the new pkgutil API on PyPM .. keeping interoperability with pip/easy_install installed packages in mind. -srid

1 0