Mailman 3 October 2009 - Distutils-SIG

ImportError running 'test' on namespace package - other package in namespace not found
by Jason R. Coombs 17 Apr '20

17 Apr '20

I've got two projects: mynamespace.myprojectA and mynamespace.myprojectB myprojectB depends on myprojectA. I'm using setuptools 0.6c8 to manage both projects. Both projects are registered using 'setup develop'. Both projects are accessible from an interactive interpreter: PS C:\Users\me\projects> python Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import mynamespace.myprojectA >>> import mynamespace.myprojectB >>> from mynamespace.myprojectA import mymoduleZ However, when I run 'setup test' in myprojectB, the tests fail with File ".mymoduleZ.py", line NNN, in [some context] from mynamespace.myprojectA.mymoduleZ import MyClassC ImportError: No module named myprojectA.mymoduleZ In setup.py, the test_suite is nose.collector. I searched and couldn't find anyone else with this problem. Is this a supported configuration? Is there something I can do to make tests work with interdependent projects with the same root namespace? If there's not something obvious I should be doing differently, I'm happy to put together a minimal test case that reproduces the problem. Any suggestions are appreciated. Sincerely, Jason R. Coombs

3 6

Upgrading dependencies
by Charlie Moad 29 Apr '18

29 Apr '18

Is it currently possible to upgrade dependencies as well when upgrading a packages? If not, this would be a really nice feature to add to easy_install. Maybe a call like: easy_install --upgrade --upgrade-deps Package Obviously it makes sense to leave this off by default. Thanks, Charlie

2 1

Changes to --find-links and --upgrade in SVN
by Phillip J. Eby 29 Apr '18

29 Apr '18

Elvelind Grandin reported a problem with the "develop" command that turned out to be a flaw in its --find-links support. Specifically, it wasn't ever processing the links. :) In the process of fixing it, I wound up cleaning up an annoying (to me, at least) quirk of the previous workings of --find-links. It used to be that find-links would always be processed first, no matter what, even if you were doing a completely local operation. This would've been especially annoying if it carried over into "develop", so I made some changes. Now, if an item passed to --find-links is local (a filename or file: URL), or a direct link to an egg or other distribution, it is indexed immediately. Remote URLs are now only retrieved if a dependency can't be resolved locally, or if you use the -U or --upgrade options (this goes for "develop" too). Note that this is a behavior change for easy_install, which was effectively treating --find-links as though you'd specified --upgrade in certain cases. So, if you're used to getting upgrades downloaded as a result of using --find-links, please note that this will no longer happen. EasyInstall will now *only* go online if a dependency can't be resolved locally, if -U or --upgrade is used, or if you provided suitable direct URLs via an argument or --find-links, or via a link in a local .html file.

2 1

Problems with svn in windows
by Sharky On PTNet 29 Apr '18

29 Apr '18

Hi, I´m trying to do "easy_install setuptools==dev" in a windows box but have an error with svn command. """... 'svn' is not recognized as an internal or external command, ...""" I have installed TortoiseSVN but it seems that don't have command line, is all with the Explorer. Can you tell me what client I may use in windows? Thanks for all, Helio Pereira Sharky @ PTNet

3 2

local development scenarios
by tgreenwood 29 Apr '18

29 Apr '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm new to distutils/and the egg system. I have not researched the archives as much as I should, so please excuse me if this is familiar territory... Q: Is it possible for dependency checks to work for non pipy deployed eggs? - A.egg - B.egg (setup_requires and install_requires A.egg) - email A and B eggs to friend - tell friend to : easy_install B - but B.egg does not install A...in fact, in my test case, it fails b/c it cannot find A in pipy - in this example, what happens if friend does not have net connection on target machine? how can they install from the eggs alone and get the dep checking to work? Q: How does my friend run the unittests on the egg that they have just installed? As I am developing, I frequently run the unittests and after every bdist_egg build, I also run the unit tests that way, too. How can the consumer do the same? Q: One of my apps is a command line app, say foo.py is a command line app that takes arg1, arg2,... How can the user run this app when it is encased in an egg? Q: How do I define my own pipy? While I like the idea of deploying there for the overall community, I don't want to send my half baked code into the wild. But I'd like to try the general functionality of having a deploy site for my beta customers. How can I set this up? Thanks in advance. - -Todd -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDl9Hfz6uXX4lQc/URAnY4AJ47DFHL/cpEltmqoUyGqzhsK5FjRACgt01v akc3Wh3IOXVv2jiS8TszhuE= =Rv/x -----END PGP SIGNATURE-----

5 12

Choice of dependencies?
by John J Lee 29 Apr '18

29 Apr '18

Is it possible for a package to depend on one of several packages, with the user having the option to pick? For example, my package P might depend on package A, plus either package B or package C. I know I could (ab)use extras_require, but in my case this is a real dependency rather than an optional extra. The other option I have is to just pick one of the dependencies (B or C in my example above), and thereby force people to install it even though it's not strictly required. Neither option seems particularly attractive. John

3 6

setuptools doc patch
by John J Lee 29 Apr '18

29 Apr '18

The comma removed by the patch below implies that users working from a Subversion checkout should not use EasyInstall to periodically fetch the latest version. That's not what you intended to say, I assume? http://peak.telecommunity.com/DevCenter/setuptools You should also inform your users of the need to run this command, if they -are working from a Subversion checkout, rather than using EasyInstall to +are working from a Subversion checkout rather than using EasyInstall to periodically fetch the latest version. Hmm, probably much better than the patch above: -You should also inform your users of the need to run this command, if they -are working from a Subversion checkout, rather than using EasyInstall to -periodically fetch the latest version. +If your users are working from a Subversion checkout rather than using +EasyInstall, you should also inform them of the need to run this command +to periodically fetch the latest version. John

2 2

Re: [Distutils] distutils install probs on suse 9.0
by Mats Wichmann 29 Apr '18

29 Apr '18

At 05:43 AM 5/18/2004, David Handy wrote: >On Tue, 18 May 2004, Floris van der Tak wrote: > >> my attempt to install the distutils on suse 9.0 (which provides python >> 2.3) fails: > >Why are you installing distutils on a system that already has Python 2.3 >installed? Python 2.3 normally comes with distutils as part of the Python >standard library. > >Did suse distribute a version of Python that had distutils removed? It should come from python-devel

2 1

Sample setup.py for Numeric Python
by Greg Ward 29 Apr '18

29 Apr '18

Hi again -- [cc'd to Paul Dubois: you said you weren't following the distutils sig anymore, but this directly concerns NumPy and I'd like to get your input!] here's that sample setup.py for NumPy. See below for discussion (and questions!). ------------------------------------------------------------------------ #!/usr/bin/env python # Setup script example for building the Numeric extension to Python. # This does sucessfully compile all the .dlls. Nothing happens # with the .py files currently. # Move this file to the Numerical directory of the LLNL numpy # distribution and run as: # python numpysetup.py --verbose build_ext # # created 1999/08 Perry Stoll __rcsid__ = "$Id: numpysetup.py,v 1.1 1999/09/12 20:42:48 gward Exp $" from distutils.core import setup setup (name = "numerical", version = "0.01", description = "Numerical Extension to Python", url = "http://www.python.org/sigs/matrix-sig/", ext_modules = [ ( '_numpy', { 'sources' : [ 'Src/_numpymodule.c', 'Src/arrayobject.c', 'Src/ufuncobject.c' ], 'include_dirs' : ['./Include'], 'def_file' : 'Src/numpy.def' } ), ( 'multiarray', { 'sources' : ['Src/multiarraymodule.c'], 'include_dirs' : ['./Include'], 'def_file': 'Src/multiarray.def' } ), ( 'umath', { 'sources': ['Src/umathmodule.c'], 'include_dirs' : ['./Include'], 'def_file' : 'Src/umath.def' } ), ( 'fftpack', { 'sources': ['Src/fftpackmodule.c', 'Src/fftpack.c'], 'include_dirs' : ['./Include'], 'def_file' : 'Src/fftpack.def' } ), ( 'lapack_lite', { 'sources' : [ 'Src/lapack_litemodule.c', 'Src/dlapack_lite.c', 'Src/zlapack_lite.c', 'Src/blas_lite.c', 'Src/f2c_lite.c' ], 'include_dirs' : ['./Include'], 'def_file' : 'Src/lapack_lite.def' } ), ( 'ranlib', { 'sources': ['Src/ranlibmodule.c', 'Src/ranlib.c', 'Src/com.c', 'Src/linpack.c', ], 'include_dirs' : ['./Include'], 'def_file' : 'Src/ranlib.def' } ), ] ) ------------------------------------------------------------------------ First, what d'you think? Too clunky and verbose? Too much information for each extension? I kind of think so, but I'm not sure how to reduce it elegantly. Right now, the internal data structures needed to compile a module are pretty obviously exposed: is this a good thing? Or should there be some more compact form for setup.py that will be expanded later into the full glory we see above? I've already made one small step towards reducing the amount of cruft by factoring 'include_dirs' out and supplying it directly as a parameter to 'setup()'. (But that needs code not in the CVS archive yet, so I've left the sample setup.py the same for now.) The next thing I'd like to do is get that damn "def_file" out of there. To support it in MSVCCompiler, there's already an ugly hack that unnecessarily affects both the UnixCCompiler and CCompiler classes, and I want to get rid of that. (I refer to passing the 'build_info' dictionary into the compiler classes, if you're familiar with the code -- that dictionary is part of the Distutils extension-building system, and should not propagate into the more general compiler classes.) But I don't want to give these weird "def file" things standing on the order of source files, object files, libraries, etc., because they seem to me to be a bizarre artifact of one particular compiler, rather than something present in a wide range of C/C++ compilers. Based on the NumPy model, it seems like there's a not-too-kludgy way to handle this problem. Namely: if building extension "foo": if file "foo.def" found in same directory as "foo.c" add "/def:foo.def" to MSVC command line this will of course require some platform-specific code in the build_ext command class, but I figured that was coming eventually, so why put it off? ;-) To make this hack work with NumPy, one change would be necessary: rename Src/numpy.def to Src/_numpy.def to match Src/_numpy.c, which implements the _numpy module. Would this be too much to ask of NumPy? (Paul?) What about other module distributions that support MSVC++ and thus ship with "def" files? Could they be made to accomodate this scheme? Thanks for your feedback -- Greg -- Greg Ward - software developer gward(a)cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913

4 5

Can now compile simple extensions
by Greg Ward 29 Apr '18

29 Apr '18

Hi all -- at long last, I found the time to hack in the ability to compile extension modules to the Distutils. Mainly, this meant adding a 'build_ext' command which uses a CCompiler instance for all its dirty work. I also had to add a few methods to CCompiler (and, of course, UnixCCompiler) to make this work. And I added a new module, 'spawn', which takes care of running sub-programs more efficiently and robustly (no shell involved) than os.system. That's needed, obviously, so we can run the compiler! If you're in the mood for grubbing over raw source code, then get the latest from CVS or download a current snapshot. See http://www.python.org/sigs/distutils-sig/implementation.html for a link to the code snapshot. I'm still waiting for more subclasses of CCompiler to appear. At the very least, we're going to need MSVCCompiler to build extensions on Windows. Any takers? Also, someone who knows the Mac, and how to run compilers programmatically there, will have to figure out how to write a Mac-specific concrete CCompiler subclass. The spawn module also needs a bit of work to be portable. I suspect that _win32_spawn() (the intended analog to my _posix_spawn()) will be easy to implement, if it even needs to go in a separate function at all. It looks from the Python Library documentation for 1.5.2 that the os.spawnv() function is all we need, but it's a bit hard to figure out just what's needed. Windows wizards, please take a look at the 'spawn()' function and see if you can make it work on Windows. As for actually compiling extensions: well, if you can figure out the build_ext command, go ahead and give it a whirl. It's a bit cryptic right now, since there's no documentation and no example setup.py. (I have a working example at home, but it's not available online.) If you feel up to it, though, see if you can read the code and figure out what's going on. I'm just hoping *I'll* be able to figure out what's going on when I get back from the O'Reilly conference next week... ;-) Enjoy -- Greg -- Greg Ward - software developer gward(a)cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913

2 1

Two fixes (at last)
by Greg Ward 29 Apr '18

29 Apr '18

Hi all -- at long last, I have fixed two problems that a couple people noticed a while ago: * I folded in Amos Latteier's NT patches almost verbatim -- just changed an `os.path.sep == "/"' to `os.name == "posix"' and added some comments bitching about the inadequacy of the current library installation model (I think this is Python's fault, but for now Distutils is slavishly aping the situation in Python 1.5.x) * I fixed the problem whereby running "setup.py install" without doing anything else caused a crash (because 'build' hadn't yet been run). Now, the 'install' command automatically runs 'build' before doing anything; to make this bearable, I added a 'have_run' dictionary to the Distribution class to keep track of which commands have been run. So now not only are command classes singletons, but their 'run' method can only be invoked once -- both restrictions enforced by Distribution. The code is checked into CVS, or you can download a snapshot at http://www.python.org/sigs/distutils-sig/distutils-19990607.tar.gz Hope someone (Amos?) can try the new version under NT. Any takers for Mac OS? BTW, all parties involved in the Great "Where Do We Install Stuff?" Debate should take a good, hard look at the 'set_final_options()' method of the Install class in distutils/install.py; this is where all the policy decisions about where to install files are made. Currently it apes the Python 1.5 situation as closely as I could figure it out. Obviously, this is subject to change -- I just don't know to *what* it will change! Greg -- Greg Ward - software developer gward(a)cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913

2 1

Package versioning
by Timothy Docker 29 Apr '18

29 Apr '18

Hi all, I've been aware that the distutils sig has been simmerring away, but until recently it has not been directly relevant to what I do. I like the look of the proposed api, but have one question. Will this support an installed system that has multiple versions of the same package installed simultaneously? If not, then this would seem to be a significant limitation, especially when dependencies between packages are considered. Assuming it does, then how will this be achieved? I am presently managing this with a messy arrangement of symlinks. A package is installed with its version number in it's name, and a separate directory is created for an application with links from the unversioned package name to the versioned one. Then I just set the pythonpath to this directory. A sample of what the directory looks like is shown below. I'm sure there is a better solution that this, and I'm not sure that this would work under windows anyway (does windows have symlinks?). So, has this SIG considered such versioning issues yet? Cheers, Tim -------------------------------------------------------------- Tim Docker timd(a)macquarie.com.au Quantative Applications Division Macquarie Bank -------------------------------------------------------------- qad16:qad $ ls -l lib/python/ total 110 drwxr-xr-x 2 mts mts 512 Nov 11 11:23 1.1 -r--r----- 1 root mts 45172 Sep 1 1998 cdrmodule_0_7_1.so drwxr-xr-x 2 mts mts 512 Sep 1 1998 chart_1_1 drwxr-xr-x 3 mts mts 512 Sep 1 1998 Fnorb_0_7_1 dr-xr-x--- 3 mts mts 512 Nov 11 11:21 Fnorb_0_8 drwxr-xr-x 3 mts mts 1536 Mar 3 12:45 mts_1_1 dr-xr-x--- 7 mts mts 512 Nov 11 11:22 OpenGL_1_5_1 dr-xr-x--- 2 mts mts 1024 Nov 11 11:23 PIL_0_3 drwxr-xr-x 3 mts mts 512 Sep 1 1998 Pmw_0_7 dr-xr-x--- 2 mts mts 512 Nov 11 11:21 v3d_1_1 qad16:qad $ ls -l lib/python/1.1 total 30 lrwxrwxrwx 1 root other 29 Apr 10 10:43 _glumodule.so -> ../OpenGL_1_5_1/_glumodule.so lrwxrwxrwx 1 root other 30 Apr 10 10:43 _glutmodule.so -> ../OpenGL_1_5_1/_glutmodule.so lrwxrwxrwx 1 root other 22 Apr 10 10:43 _imaging.so -> ../PIL_0_3/_imaging.so lrwxrwxrwx 1 root other 36 Apr 10 10:43 _opengl_nummodule.so -> ../OpenGL_1_5_1/_opengl_nummodule.so lrwxrwxrwx 1 root other 27 Apr 10 10:43 _tkinter.so -> ../OpenGL_1_5_1/_tkinter.so lrwxrwxrwx 1 mts mts 21 Apr 10 10:43 cdrmodule.so -> ../cdrmodule_0_7_1.so lrwxrwxrwx 1 mts mts 12 Apr 10 10:43 chart -> ../chart_1_1 lrwxrwxrwx 1 root other 12 Apr 10 10:43 Fnorb -> ../Fnorb_0_8 lrwxrwxrwx 1 mts mts 12 Apr 10 10:43 mts -> ../mts_1_1 lrwxrwxrwx 1 root other 15 Apr 10 10:43 OpenGL -> ../OpenGL_1_5_1 lrwxrwxrwx 1 root other 33 Apr 10 10:43 opengltrmodule.so -> ../OpenGL_1_5_1/opengltrmodule.so lrwxrwxrwx 1 root other 33 Apr 10 10:43 openglutil_num.so -> ../OpenGL_1_5_1/openglutil_num.so lrwxrwxrwx 1 root other 10 Apr 10 10:43 PIL -> ../PIL_0_3 lrwxrwxrwx 1 mts mts 10 Apr 10 10:43 Pmw -> ../Pmw_0_7 lrwxrwxrwx 1 root other 10 Apr 10 10:43 v3d -> ../v3d_1_1

3 2

[Distutils-sig] distutils charter and interscript
by John Skaller 29 Apr '18

29 Apr '18

3 2

Distribute sprint #2, next sunday
by Tarek Ziadé 03 Nov '09

03 Nov '09

Hey, We will have a sprint sunday afternoon, starting at 3 pm in Berlin/Germany. If you are interested you can join online in the irc (#distutils on Freenode) or in Berlin of course. This sprint will continue the work we've started on the 0.7 branch. If you have worked during the first sprint and you can't make it sunday, please make sure your worked was commited in the Distribute repository with notes so we can continue. Cheers Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与

1 1

PEP 390 - new format from setup.cfg
by Tarek Ziadé 03 Nov '09

03 Nov '09

Hey this is the PEP for setup.cfg, as requested : http://www.python.org/dev/peps/pep-0390 Please comment, Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与

14 101

Re: [Distutils] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
by Chris Withers 31 Oct '09

31 Oct '09

Paul Moore wrote: > 2009/10/20 Ian Bicking <ianb(a)colorstudy.com>: >> Well, I wanted to move it off python-dev, and I didn't really feel >> like moving it onto distutils-sig because I felt the debate was not >> particularly important to introduce the confusion of a half-started >> thread. > > Sorry, I hadn't realised it was on python-dev rather than > distutils-sig. You're right in that case. > >> My point is the bdist_win installers work fine for both your use case, >> Paul, and Chris' use case, so there's no real conflict. > > OK, and yet people still seem to argue for eggs rather than > bdist_wininst, and projects provide eggs rather than bdist_wininst. > Something's not working here, even though logic says it should. Well, speaking only for myself, I never use bdist_wininst packages because they do no dependency management. If I release a package that has no external dependencies, I'll stick a bdist_msi or bdist_wininst if asked, but it's rarely asked for. From that I infer that most people use tools like buildout or pip to manage installation, even on Windows. Again, as a package consumer, I prefer one cross-platform package management method for Python packages, regardless of what operating system I happen to be working on at the time... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

9 17

distribute and buildout: best practices?
by Reinout van Rees 28 Oct '09

28 Oct '09

What's the current best way to use both distribute and buildout? Apart from the bootstrap + apparently needed change in buildout, I've got the following questions: - Do my libraries have to list a dependency on distribute or on setuptools? Everything zopish has a 'setuptools >= 0.6c9' in it. I tried putting distribute in there, but I seemed to get less problems with leaving it at setuptools. - Should just globally installing distribute be enough? Everything ought to keep working. It does lead to a bunch of runtime warnings in buildout, however. (But Tarek has targeted that problem for the upcoming 0.6.4 :-) - Do I need to change buildout's bootstrap already? Doing that tries to change my global setuptools, for which you need to sudo. And it also forces everyone else using that buildout to switch (which in itself is OK). - From my experiments (not exhaustive! no real debugging!) it seems that the only safe way is to first install distribute globally before touching a buildout that brings in distribute. Is this to be expected? Reinout -- Reinout van Rees - reinout(a)vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com "Military engineers build missiles. Civil engineers build targets"

11 38

[issue88] urllib2.splituser
by Jürgen Hermann 28 Oct '09

28 Oct '09

New submission from Jürgen Hermann <Juergen.Hermann(a)1und1.de>: setuptools/package_index.py throws an AttributeError in Python 2.3 due to auth, host = urllib2.splituser(netloc) It either needs the following monkey patch, or simply use splituser from urllib. import urllib import urllib2 if not hasattr(urllib2, 'splituser'): # setuptools wants to import this from urllib2 but it's not # in there in Python 2.3.3, so we just alias it. urllib2.splituser = urllib.splituser ---------- messages: 441 nosy: jhe priority: bug status: unread title: urllib2.splituser _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue88> _______________________________________________

1 0

Re: [Distutils] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
by Chris Withers 27 Oct '09

27 Oct '09

[adding in disutils-sig and leaving this message intact as that's where it belongs] Paul Moore wrote: > 2009/10/20 Ian Bicking <ianb(a)colorstudy.com>: >> FWIW, I don't think there's a real conflict here. My understanding is >> that wininst installers can be treated as installable packages that >> don't *have* to go through the system package manager, so they are >> both installable system-wide and installable much like an egg or >> tarball is (you can't drop the wininst installer into the path >> directly like you can an egg, but that doesn't seem to be a >> widely-held goal). > > The conflict lies in the fact that I want the features that > bdist_wininst installers give me (integration with add/remove programs > and uninstallation) [1]. If every project offers a bdist_wininst > installer, I'm happy. But Chris isn't unless they provide his > preferred format (I'm not sure if Chris has a concrete suggestion, or > he's just speculating at the moment) as well. Huh? I don't really care how packages are installed, provided they end up in a consistent format on disk. I'm not sure how a bdist_wininst installer is going to make sure a package's dependencies are met though... > I'm assuming (based on experience with eggs) that projects won't > routinely provide all possible formats. Hence my contention that a > single format is necessary. > > Having multiple package management systems that consume that format is > fine by me. But easy_install can consume bdist_wininst installers, so > the evidence is that there's more needed for a single format to emerge > than has been done so far (otherwise why isn't bdist_wininst that > single format right now?) Because not everyone runs on Windows? Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

1 0

tracking requested vs dependency installs in PEP 376 metadata
by Carl Meyer 27 Oct '09

27 Oct '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey all, I propose adding a bit to the PEP 376 metadata that indicates whether a package was installed by user request or as a dependency of another package. This would allow (un)installer tools to intelligently remove orphaned dependencies, if they so choose. There might be questions about the details of such an uninstaller feature, but I'm not intending to discuss that here. The metadata itself is simple enough to track, and seems like it ought to be included for its future usefulness. I propose adding a metadata file REQUIRED within the .egg-info directory. The presence of this file indicates that the user specifically required this distribution. The absence of the file indicates that the distribution was installed as a dependency. The contents of the file are not used. For the API, I propose adding a "required" property to the Distribution class, which would be True or False based on the presence or absence of the REQUIRED file. I've added a demo implementation to a fork of Tarek's pep376 repo on bitbucket: http://bitbucket.org/carljm/pep376/changeset/0c8002e65cb7/ Thoughts? Carl -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFKzhXFFRcxmeyPUXIRAvPkAJ4+bBPrt0fvYi2u/LhpLo2KS9ImfACfX9oq 5gab4TRuuWWUknOO0SK2E6I= =Dm+n -----END PGP SIGNATURE-----

12 37

[RFC] PEP 345 and PEP 386 updates
by Tarek Ziadé 27 Oct '09

27 Oct '09

Hi, PEP 345 is the PEP for the new metadata format, replacing PEP 314. I have upgraded it, using Tres's work from last year, and the next step is to add the context marker presented in PEP 390. I have also updated PEP 386 to link it to PEP 345. = PEP 345 : Summary of Differences From PEP 314 = * Metadata-Version is now 1.2. * Added fields: - Maintainer - Maintainer-email - Requires-Python - Requires-External - Requires-Dist - Provides-Dist - Obsoletes-Dist * Deprecated fields: - Requires (in favor of Requires-Dist) - Provides (in favor of Provides-Dist) - Obsoletes (in favor of Obsoletes-Dist) Please comment! Tarek

10 29

Distribute 0.6.7 this week
by Tarek Ziadé 27 Oct '09

27 Oct '09

Hello We are going to release 0.6.7 this week. Among some new bugs fixes, we want to provide a specific change that will allow virtualenv to be released with an option to use Distribute instead of Setuptools, like zc.buildout. $ virtualenv --distribute ENV If you want to see another bug fixed in this release, speak up ! (http://bitbucket.org/tarek/distribute/issues) Regards Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与

2 4

[buildout] A few pending issues
by Kai Lautaportti 25 Oct '09

25 Oct '09

Hi, I've reported a few issues on the zc.buildout bug tracker, mainly https://bugs.launchpad.net/zc.buildout/+bug/435837 https://bugs.launchpad.net/zc.buildout/+bug/439387 with proposed patches that I would be interested in having included in the next release of zc.buildout. The #439387 issue is trivial, but I am not sure if the patch I proposed for #435837 is appropriate and would appreciate some additional reviewing and feedback. I would also like to get https://bugs.launchpad.net/zc.buildout/+bug/113085 fixed to make zc.buildout interact better with buildbot. Has anyone looked into this lately? In any case, I would be willing to spend time on these issues during the upcoming Plone conference sprint to make sure the fixes get merged into trunk. Is there anything special I can do to make this happen? Cheers, Kai -- Kai Lautaportti

3 4

Distribute sprint #1 wrapup
by Tarek Ziadé 24 Oct '09

24 Oct '09

As promised, here's a quick wrapup of the work started during the first sprint, on Distribute 0.7 Thanks to all the people that have participated (we were 6 or 7 IIRC) If you have sprinted and see a mistake or something missing is the wrapup, please complete it; = The fate of 0.6 code = First of all, we've discussed what is happening to the 0.6 code and we've decided that it was better to keep it under the pillow as a reference code, and code everything from scratch. The only code that is going to be recycled is some parts of pkg_resources. = 0.7 philosophy = Distribute 0.7 will be a good Distutils citizen and wants to be its incubator. It will implement Distutils commands, without changing Distutils behavior as it is doing now. Another important point is that the Distribute development will be driven by the PEP work that is going on and drop most other concepts of Setuptools: - PEP 376 : a *single* installation standard - PEP 345 : Requires, Obsoletes, etc, fields - PEP 390 : platform-dependant markers for the metadata - PEP 382 : namespace packages - PEP 386 : a new version scheme Distribute will implement those PEPs by gathering all the prototypes that have been created in the past months and when possible, will try to push them in Distutils. The biggest drops we are making are: - the egg formats are removed in favor of a unique PEP 376 standard. - easy_install is removed, and Distribute will cooperate with the pip project What's unclear right now is what will be pushed in Distutils by the time Python 2.7 and 3.3 are out. = what was started during the sprint = We started to write Distutils commands: - develop command: * Created a skeleton command for develop * Waiting for work to complete on the install and build_egg_info commands before work can continue here. - build_egg_info command (in setuptools, it was called "egg_info", we've renamed it): * Rewrote this command using setuptools code as a model * Removed all SVN support code * Removed obsolete egg-info writers * Waiting on the manifest generation feature to finish this one * Will implement PEP 376 egg-info writers when possible - generate_manifest command. Not started yet, but will be used to generate the MANIFEST file, and provide a plugin system for VCS support. (not an implicit system like in Setuptools) - install command - building a PEP 376 compatible install command (by rewriting pkg_resources, using the PEP 376 prototype we have written some time ago) - distutils.extensions : lightweight entry points, based on the PEP 376 standard taken back from the "extensions" project - Currently working on testing strategy = next sprint = The next sprint will be next week-end, and will be announced here; Anyone can join ! Thanks Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与

3 6

Distribute support added in zc.buildout
by Tarek Ziadé 24 Oct '09

24 Oct '09

Hey, I have added in zc.buildout trunk the Distribute support. The unified bootstrap now has a --distribute boolean option that allows you to switch if you want. its located here as usual : http://svn.zope.org/*checkout*/zc.buildout/trunk/bootstrap/bootstrap.py Please try it ! I will wait a few days to make sure everything works as expected then push a zc.buildout 1.4.2 release that includes this change Cheers Tarek

6 14

First attempt: close but no data files!
by Kaelin Colclasure 23 Oct '09

23 Oct '09

Greetings, I am attempting my first Python contribution and have run into a speed bump getting a working setup.py using setuptools. Specifically, I cannot coax it to install my package data files into the site-packages directory. Here is a link to my project where my setup.py is available for browsing: <http://bitbucket.org/kaelin/cuttlefish/> Soooo close! TIA, -- Kaelin

3 9

zc.buildout and site-packages
by Martin Aspeli 23 Oct '09

23 Oct '09

Hi, Is there a way (apart from putting buildout in a virtualenv with --no-site- packages) to tell buildout *not* to put site-packages as the first line in the mangled sys.path when it generates scripts? We have people doing horrid things to their global python, and we need the buildout to be safe and isolated in these environments. Martin

5 4

Preparing Distribute sprint #1 wrapup
by Tarek Ziadé 22 Oct '09

22 Oct '09

Hey, Thanks to all sprinters, this was fun. Another sprint will be soon planned. I'd like to write a wrapup of the sprint we've done, so we can explain what's been done and what's next. If you were at that sprint and a "nominated" leader of one of the team, please add a summary of what has been done so far in your team, with links to the repositories when needed here : http://wiki.python.org/moin/Distutils/DistributeSprint (or a link to your blog if this has been done there) Thank you ! Tarek

1 0

Re: [Distutils] [Python-Dev] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
by Chris Withers 20 Oct '09

20 Oct '09

Chris Withers wrote: > [following up on distutils-sig] > > Michael Foord wrote: >> Many Windows users would be quite happy if the standard mechanism for >> installing non-source distributions on Windows was via the wininst >> binaries. > > ...and many users may not be ;-) I know I'd be extremely unhappy if that > were the case as I routines use multiple versions of packages with > multiple versions of python on one machine... > >> I wonder if it is going to be possible to make this compatible with >> the upcoming distutils package management 'stuff' (querying for >> installed packages, uninstallation etc) since >> installation/uninstallation goes through the Windows system package >> management feature. I guess it would be eminently possible but >> require some reasonably high level Windows-fu to do. > > I wouldn't have a problem if integrating with the windows package > manager was an optional extra, but I think it's one of many types of > package management that need to be worried about, so might be easier to > get the others working and let anyone who wants anything beyond a > pure-python packaging system that works across platforms, regardless of > whether binary extensions are needed, do the work themselves... > > Chris > -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

1 0

Setuptools 0.6c11 released
by P.J. Eby 20 Oct '09

20 Oct '09

Oops! ----- Due to a couple of last-minute issues with the 0.6c10 release, I've released an 0.6c11 update at: http://pypi.python.org/setuptools/ It fixes an error when running the "sdist" command on a package with no README, and includes the 64-bit Windows fix that was promised in 0.6c10 but wasn't actually checked in to SVN. You can install the updated version using easy_install (or pip!), by asking for setuptools==0.6c11. The Fine Print -------------- (Note for users of Distribute: Distribute and setuptools use the same package name 'setuptools', and thus cannot both be present on the same sys.path (e.g. in the same virtualenv). If you wish to switch a given environment from Distribute to setuptools or vice versa, you will need to completely uninstall one before installing the other. If you currently have Distribute installed, please follow Distribute's uninstall instructions if you wish to reinstall setuptools.) Please report any bugs to the setuptools bug tracker at: http://bugs.python.org/setuptools/ For faster response to questions, please use the distutils-sig mailing list, rather than the tracker. Setuptools documentation can be found via links at http://pypi.python.org/pypi/setuptools#using-setuptools-and-easyinstall -- and the pages on the PEAK wiki now load much, much faster than they did a few months ago. (They're static cached pages now, rather than dynamically generated, unless you're actually logged into the wiki.)

1 0

Re: [Distutils] supporting multiple versions of one package in one environment is insane
by Chris Withers 20 Oct '09

20 Oct '09

[moving to disutils-sig where this belongs] Toshio Kuratomi wrote: >>> where type of problem == sandboxed environment, sure. How do you solve the >>> problem for system packagers? >> What's to stop a system packager either just running the buildout on >> install, or running the buildout at package build time and then just >> dropping the resulting environment wherever they want to install >> applications? Such a package would only be dependent on the right python >> version at runtime... >> > If buildout creates sandboxed environments like virtualenv then everything > here applies: > > https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries That's fine, buildout can use a shared eggs directory (it's how I run it by default, to minimise the amount of downloading that goes on). In that case, there would be no duplication of packages, the "installed app" would just pick from a folder full of eggs that you could put wherever your OS wants them... In short, have multiple versions of a python package on the python path at the same time is insane ;-) Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

1 0

Package install failures in 2.6.3 - setuptools vs Distribute
by Ned Deily 20 Oct '09

20 Oct '09

I'm afraid there is going to be a small deluge of very confused users who will end up needing to install Distribute but only when they eventually figure out why some packages with C extensions mysteriously no longer install after they upgrade to python 2.6.3. For example, following the package instructions to use setuptools easy_install, an easy_install lxml fails with 2.6.3 with the very cryptic: File "build/bdist.macosx-10.3-fat/egg/setuptools/command/build_ext.py", line 85, in get_ext_filename KeyError: 'etree' http://stackoverflow.com/questions/1512530/cant-install-lxml-python-2-6-3 -osx-10-6-snow-leopard Appscript is another package that fails similarly. There must be others. I don't know what's to be done about this awkward incompatibility now that 2.6.3 is out the door other than perhaps making sure maintainers of affected packages are aware of what their users are running into and can update their documentation. There is one small thing that may help some users who find their way to http://pypi.python.org/pypi/distribute. OS X, for one, does not ship with wget however it does have curl. Suggest adding another example: $ curl -O http://nightly.ziade.org/distribute_setup.py $ python distribute_setup.py -- Ned Deily, nad(a)acm.org

21 88

[RFC] Recentering the static metadata need : PKG-INFO
by Tarek Ziadé 20 Oct '09

20 Oct '09

Hey, Marc-André Lemburg gave me a key points about the static metadata discussions we have (wether its PEP 390 or around it) He said that the important thing was to have the context-dependant markers in PKG-INFO, and that having in described in setup.cfg or in setup.py by any way is not the important thing. And he is right ! So, PEP 390 proposes a new setup.cfg format, that's fine. And others are thinking about other ways to build metadata, that's great. But what really matters at the end is to provide a new Metadata format where these marker are present, so any consumer can play with them (and Distutils provide an API to play with them : the DistributionMetadata class) So please, have a look at the new section I've added here with the syntax I am proposing : http://www.python.org/dev/peps/pep-0390/#impact-on-pkg-info-generation-and-… That will probably re-center the debate in creating a Metadata 1.2 format that includes these markers. As someone asked, here is the principal uses cases of having static metadata that includes markers like this: - pip, or easy_install, or any client code, will be able to query PyPI, to get the metadata of a package. *and* will be able to have it depending on a particular environment. - it will be possible to generate and provide alongside the source code the PKG-INFO file, like how install_egg_info does at installation time, exactly like how MANIFEST is built. If that sounds like the right path (it does to me), we could start to work on a PEP 314 update, and add in the work what was started last year: - revision of "requires", "obsoletes", etc.. - link to PEP 386 Regards Tarek

6 18

buglet in setuptools 0.6c10
by Barry Warsaw 20 Oct '09

20 Oct '09

Sorry for the lame-ass bug report, but my stack is really deep and I didn't want this one to go unreported. I just tried 0.6c10 to see if it would fix a problem I'm having. How fortunate that it hit Cheeseshop at just the right time ;). Unfortunately, there's a bug in setuptools/command/sdist.py Line 184 references string.join, but 'string' is undefined. -Barry

3 4

Avoid dependency_links / find_links
by Patrice Neff 19 Oct '09

19 Oct '09

Hi, We manage our projects with setuptools. For this we have a local PyPi mirror with just our required packages. This mirror is specified in our setuptools environments using the index_url directive. The basic idea is: we don't want to access the internet when installing packages. Today I had to realized that we haven't been reaching that goal as Pylons contains a dependency_links pointing to pylonshq.com. So the question would be: is there any way to avoid following any dependency_links and/or find_links paths and only use the index_url? I have quickly checked the setuptools source code and couldn't find any way to do this. Would a patch be accepted if I implemented that behavior? Are there other approaches to do what I'm trying to do? Thanks in advance Patrice

2 2

Setuptools 0.6c10 released
by P.J. Eby 19 Oct '09

19 Oct '09

The long-overdue setuptools 0.6c10 update is now available on PyPI, at: http://pypi.python.org/setuptools/ Major updates and fixes include: * Support for SVN 1.6 and Python 2.6 * Fix for the Python 2.6.3 build_ext API change * Support for the most recent Sourceforge download link insanity * Fix for Vista UAC errors running easy_install.exe or other "installer-looking" executables * Fix for errors launching 64-bit Windows Python * Stop crashing on certain types of HTTP error * Stop re-trying URLs that already failed retrieval once * Fixes for various dependency management problems such as looping builds, re-downloading packages already present on sys.path (but not in a registered "site" directory), and randomly preferring local -f packages over local installed packages * Prevent lots of spurious "already imported from another path" warnings (e.g. when pkg_resources is imported late) * Ensure C libraries (as opposed to extensions) are also built when doing bdist_egg Other changes: * Misc. documentation fixes * Improved Jython support * Fewer warnings under Python 2.6+ * Warn when 'packages' uses paths instead of package names (because it causes other problems, like spurious "already imported" warnings) * Stop using /usr/bin/sw_vers on Mac OS (replaced w/'platform' module calls) You can install the updated version using easy_install (or pip!), asking for setuptools==0.6c10. (Note for users of Distribute: Distribute and setuptools use the same package name 'setuptools', and thus cannot both be present on the same sys.path (e.g. in the same virtualenv). If you wish to switch a given environment from Distribute to setuptools or vice versa, you will need to completely uninstall one before installing the other. If you currently have Distribute installed, please follow Distribute's uninstall instructions if you wish to reinstall setuptools.) Please report any problems with setuptools to the setuptools bug tracker at: http://bugs.python.org/setuptools/ For faster response to questions, please use the distutils-sig mailing list, rather than the tracker. Setuptools documentation can be found via links at http://pypi.python.org/pypi/setuptools#using-setuptools-and-easyinstall -- and the pages on the PEAK wiki now load much, much faster than they did a few months ago. (They're static cached pages now, rather than dynamically generated, unless you're actually logged into the wiki.)

2 2

[buildout] Fixed verbose mode when developing eggs
by Jonathan Ballet 19 Oct '09

19 Oct '09

Hello, I had a small headache using Buildout this morning: I had a package which contained a C extension and which was developed in my buildout.cfg file. I wanted to see what was the gcc call used to build this extension, but using as much as -v as I could (I stopped at ten), I didn't see anything more. So, I dig in the code, and there was a typo in easy_install.py, which is fixed in fix-verbose-develop.patch (this needs a test to be updated, BTW). The fix was trivial (replacing "==" with "="), but I think the way args is build is now better. I propose also another patch (uniformize-args.patch), which refactors args construction using a list instead of a tuple, which looks smarter (why a tuple whereas it is updated several times?). This is not mandatory for the fix, feel free to integrate it or not. Cheers, Jonathan

2 1

Brand new, clean server, set up from scratch, buildbot still fails
by Steve Steiner 19 Oct '09

19 Oct '09

http://pastebin.com/m69796bc5 This is running on a bare system, after figuring out which development tools were needed, all the version control systems necessary etc. I have all that captured in my Fabric script so we're all set for being able to duplicate it. I have NOT installed anything into the system Python at all. In fact, other than the tools necessary to pull the products out of VCS, and the compilers and such, I haven't installed (or done) anything to the system at all. That's kind of the point. We want to be able to go from bare metal to running buildbot completely automatically. I don't quite understand what this thing is supposed to be doing but I'm sure it's not doing everything it needs to do to get itself "bootstrapped"; on a fresh Ubuntu install, anyway. BTW, on my OS X development system, running the system Python 2.6.1, it doesn't have any trouble at all except for this little gem early in the process. /usr/bin/python "-c" "from setuptools.command.easy_install import main; main()" "-mUNxd" "/Users/ssteiner/Dropbox/work/distutils-builbot/ eggs/tmptMBdZk" "-q" "/Users/ssteiner/Dropbox/src/twisted_trunk" path=/Users/ssteiner/Dropbox/work/distutils-builbot/eggs/ setuptools-0.6c9-py2.6.egg /Library/Python/2.6/site-packages/Pyrex-0.9.8.5-py2.6.egg/Pyrex/ Compiler/Errors.py:17: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6 self.message = message unrecognized .svn/entries format in conftest.c:1:23: error: sys/epoll.h: No such file or directory conftest.c:1:23: error: sys/epoll.h: No such file or directory conftest.c:1:23: error: sys/epoll.h: No such file or directory lipo: can't open input file: /var/folders/28/28Xggq0cGXqLpT1Uz5Gk4E++ +TI/-Tmp-//ccOmCair.out (No such file or directory) Got Twisted 8.2.0-r27376. Picked: Twisted = 8.2.0-r27376 Getting required 'zope.interface' required by collective.buildbot 0.3.5. required by Twisted 8.2.0-r27376. ... and then it carries on. However, when trying to run it with /bin/test, something tries to refer to "trunk-checkout" when the python trunk was actually checked out into python-trunk. (~/work/distutils-builbot)# bin/test Traceback (most recent call last): File "bin/test", line 12, in <module> os.chdir(python_trunk) OSError: [Errno 2] No such file or directory: '/Users/ssteiner/work/ distutils-builbot/parts/trunk-checkout/python' All in all, I really can't get it to build or run anywhere at this point... S

3 9

Checking mailing list for Distribute
by Tarek Ziadé 18 Oct '09

18 Oct '09

Hey, if you want to follow the commits diffs and the issues for Distribute, there's now a distinct mailing list you can follow : http://groups.google.fr/group/distribute-checkins Regards Tarek

1 0

Buildbot throwing a gear after default setup?
by ssteinerX＠gmail.com 18 Oct '09

18 Oct '09

I've just downloaded and configured the Distribute buildbot and it appears that a dependency is missing somewhere. I get this (just the errors excerpted). Just wanted to capture this before I figure out what needs to be done... test_make_tarball (distutils.tests.test_archive_util.ArchiveUtilTestCase) ... skipped 'requires zlib' test_make_zipfile (distutils.tests.test_archive_util.ArchiveUtilTestCase) ... skipped 'Requires zlib' test_tarfile_root_owner (distutils.tests.test_archive_util.ArchiveUtilTestCase) ... skipped 'Requires zlib' test_tarfile_vs_tar (distutils.tests.test_archive_util.ArchiveUtilTestCase) ... skipped 'Requires zlib' ====================================================================== ERROR: test_make_archive_owner_group (distutils.tests.test_archive_util.ArchiveUtilTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/ssteiner/distutils-builbot/parts/trunk-checkout/python/ Lib/distutils/tests/test_archive_util.py", line 224, in test_make_archive_owner_group group=group) File "/home/ssteiner/distutils-builbot/parts/trunk-checkout/python/ Lib/distutils/archive_util.py", line 236, in make_archive filename = func(base_name, base_dir, **kwargs) File "/home/ssteiner/distutils-builbot/parts/trunk-checkout/python/ Lib/distutils/archive_util.py", line 163, in make_zipfile compression=zipfile.ZIP_DEFLATED) File "/home/ssteiner/distutils-builbot/parts/trunk-checkout/python/ Lib/zipfile.py", line 675, in __init__ "Compression requires the (missing) zlib module" RuntimeError: Compression requires the (missing) zlib module ---------------------------------------------------------------------- Ran 158 tests in 1.242s FAILED (errors=1, skipped=11) test test_distutils crashed -- <type 'exceptions.OSError'>: [Errno 2] No such file or directory Traceback (most recent call last): File "Lib/test/regrtest.py", line 767, in runtest_inner File "Lib/test/regrtest.py", line 723, in __exit__ File "Lib/test/regrtest.py", line 686, in get_cwd OSError: [Errno 2] No such file or directory 1 test failed: test_distutils

5 27

Distribute 0.7.x first sprint
by Tarek Ziadé 18 Oct '09

18 Oct '09

Hey While we are working at fixing bugs in 0.6.x, I would like to organize a first online coding sprint for the 0.7.x series, goals: - finalize the first splitting version - define a more detailed roadmap for each splitted package - build a better test environment (see if we can set up a buildbot) possible times: - Sunday October 18th - 6 pm. GMT+2 - Tuesday October 20th - 7 pm. GMT+2 - Wenesday October 21th - 7 pm. GMT+2 - Friday October 23th - 7 pm. GMT+2 If you want to join, add your name here: http://doodle.com/bfgv3yi3pi48buuv Thanks -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与

1 1

setuptools 0.6c10 delayed until Monday
by P.J. Eby 17 Oct '09

17 Oct '09

After giving it some thought, I've decided to hold off on pushing out the 0.6c10 release until Monday morning, since it's likely that some people have scripts or build processes that run off of ez_setup SVN or the latest PyPI version of setuptools... and who aren't aware the release is coming and might be surprised by it. It would therefore probably not be a good idea to push this out on a Friday. Also, this will give those who are using Distribute and do *not* wish to use this release, a chance to upgrade to the latest version of Distribute first. (Which, if I understand correctly, includes code to prevent accidental re-installation of setuptools.)

2 2

making windows exe file on linux
by james27 17 Oct '09

17 Oct '09

hello im new to cx_freeze . and also new to python. i want to make windows exe executable file on linux. i was searched much of time.but i couldn't found solution. is it possible to make windows exe file by use cx_freeze on linux? or there is some other solution is exist? if anyone can help ,much appreciate. thanks in advance. paul. -- View this message in context: http://www.nabble.com/making-windows-exe-file-on-linux-tp25937633p25937633.… Sent from the Python - distutils-sig mailing list archive at Nabble.com.

1 0

Re: [Distutils] Proposal for Distribute 0.7
by P.J. Eby 17 Oct '09

17 Oct '09

At 02:32 PM 10/15/2009 +0200, Tarek Ziadé wrote: >That would make us happy, because we would be able to work and >continue if you are not available sometimes without the feeling >that we are locked, and that would give you the manpower you miss to >develop some of your idea. So... you've explained what part of this proposal will make you happy. Where's the part that will make me happy? Generally speaking, that's how a "win-win" proposal works. There's a second issue, too. You've repeatedly smeared setuptools on Python-Dev to cover your mistakes, and you have *yet* to retract or amend any of those statements or apologize for them in any of the places where you made them -- despite numerous requests that you do so. In each case where I've made a request, I know you've received the request, because you've replied to the email or comment in which I made it. But in none of your replies have you even *acknowledged* the issue, let alone done anything about it. Instead, you've either changed the venue, the subject, or just launched a new smear. This latest "proposal" of yours is of course just another such subject and venue change, in reply to one of my more recent requests (via Reddit comment) that you do something about this outstanding issue. But if you were genuinely serious about the things you claim to be interested in, you might have paid attention to such things as my mentions that there are other people on the Distribute team who I'd seriously consider as committers on setuptools or even as a chief maintainer of the setuptools 0.6 line (if not more). In my book, the mere fact that you haven't asked me who those team members are, or offered to step down in favor of them (either privately OR publicly), tells me everything I need to know about where your real interest in this matter lies. Now, don't get me wrong - I'm not blacklisting you or refusing to support you. You are no less a user of setuptools than any other, after all. To the extent that you are courteous in your requests regarding setuptools, you will get reasonably courteous responses from me, as has been the case on Python-Dev and here in the last few days. (And for that matter, all along!) But please don't bother floating any more proposals for some sort of direct collaboration or co-operation between you and I, not now, or ever again, until such time as you have shown as consistent a track record of behaving with integrity, as you've shown a *lack of* in your interactions with me. Because as of right now, I can't trust you enough to work with you. I can't trust you not to blame every mistake you make on me, and then say, "oh let's just forget about everything" when you're called on it. I can't trust you to admit when you don't know something (see our recent Catalog-SIG exchange), or to not throw my agreement to work with you back in my face the first time we disagree on something. And these things alone would be more than enough reason not to work on a software project with someone. But at this point, I can't even trust you to not immediately follow up my mere *agreement* to work with you, with a blog post like "PJE finally comes to his senses" or some such rubbish. Your political gaming behavior is a deal-breaker for me, and it's not something that any behavior you do *now* can fix. I've tried for months to give you the benefit of the doubt, the benefit of the language barrier, and maybe even the benefit of a complete lack of sensitivity or clue on your part. And, most recently, you've had no fewer than *five* extra chances from me to act with integrity, but you've chosen to showboat instead. Every. Single. Time. So, good luck with that, 'cause I'm done with it. To the rest of the Distribute team: I have absolutely no quarrel with any of you, as far as I know, and I remain open to an (off-list) discussion on any topics or win-win proposals you'd like to discuss. P.S. Tarek: if your next move is to issue a series of halfhearted, backhanded retractions so you can whine that you did what I asked and I still won't work with you, please don't bother. It's not really credible evidence of your integrity at this point, so I'm done with asking you for anything. IOW, this is *not* a sixth request for a retraction, it's the termination of my many, many attempts to deal with you in good faith. P.P.S. Everyone else: please don't clog the SIG mailing list with further discussion on this topic. If you feel the need to flame me for some reason, please show more consideration to the group than Tarek has, by sending it to me in private, or go rant on your blog or twitter if your need for attention is too great. In return, I will guarantee this to be my last mailing list post on this subject. (I guarantee that I'm at *least* as tired of it as you are.) Thanks in advance.

6 14

Re: [Distutils] [venv] Re: two questions about virtualenv
by ssteinerX＠gmail.com 16 Oct '09

16 Oct '09

On Oct 16, 2009, at 12:25 PM, Brandon Craig Rhodes wrote: > Jannis Leidel <jannis(a)leidel.info> writes: > >> That'd be very much appreciated, I'm sure the experience of the >> distribute people would be helpful, too. > > I'm not sure I quite approve of their approach, since it makes > installing Distribute under Python 3 take a very long time - which, > as a > result, currently makes creating a virtualenv under Python 3 take a > very > long time as well. Someone was complaining to me about that just > earlier this week. Doesn't that also mean that the Python 3 version of Distribute is generated live on the installation system? That doesn't seem right because that leaves the possibility that the code generated by 2to3 is different from the code that passed the (hypothetical, at this point) tests before the distribution was created. I'm going to cross-post this to the distutils list as well. If the idea is to stabilize Distribute, get some tests in place, etc. then this method of distribution (running 2to3 in situ, as it were) is not the correct way to do it from a "shipping the tested product" perspective. S

4 6

small distribute improvement
by Neal Becker 16 Oct '09

16 Oct '09

I think it is confusing that easy_install blah doesn't do anything, and doesn't provide any clue, if it was to do an update. You need to say easy_install -U blah There are a few choices here. One might be that easy_install blah could notify you that an update is available. Personally, my preference would be to just do the update. Or, at least offer to if run interactively.

4 3

distribute 0.6.6 is out
by Reinout van Rees 15 Oct '09

15 Oct '09

Tarek is off to bed, so I'll throw out a quick mail to bring you all the happy tiding that distribute 0.6.6 is out! So get ready for your "easy_install -U distribute". Buildout users can grab http://python-distribute.org/bootstrap.py and get their bin/buildout to use this stable 0.6.6. Works like a charm. (Note: tiny update-time bug in 0.6.5, so thatâs why thereâs a 0.6.6) Reinout -- Reinout van Rees - reinout(a)vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com "Military engineers build missiles. Civil engineers build targets"

2 1

Distribute docs at packages.python.org?
by John Gabriele 15 Oct '09

15 Oct '09

Was just looking at the Distribute docs at http://packages.python.org/distribute/index.html (nicely styled, btw). Are there any other projects at http://packages.python.org/ (note, that page actually doesn't even load)? What is the purpose of packages.python.org , and how does one get their project listed there? Btw, regarding the Distribute docs there, thanks for the Roadmap! ---John

2 1

distribute equivalent of "setup.py develop"?
by Andreas Klöckner 15 Oct '09

15 Oct '09

Hi there, I've recently tried distribute, and much to my dismay found that it doesn't appear to contain an equivalent of "setup.py develop". Is such a thing planned, or, even better, available now? Thanks, Andreas

2 3

Proposal for Distribute 0.7
by Tarek Ziadé 15 Oct '09

15 Oct '09

Phillip, I have a proposal for Distribute 0.7 : let's join forces and all work together in that tool. "All" would be the commiters of Distribute, and PJE. These people would all be in the same team with the same commiter rights, and I propose that you become the leader of that tool and guide us in its development. (but with the usual +1/-1 stuff of course) That would make us happy, because we would be able to work and continue if you are not available sometimes without the feeling that we are locked, and that would give you the manpower you miss to develop some of your idea. That would be the best thing that could happen imho for python packaging. And if you agree, and want the project name, we can all find a neutral name that everybody would like. Cheers, Tarek

1 1

Distribute 0.6.5 coming up
by Tarek Ziadé 15 Oct '09

15 Oct '09

Hey, Reinout and I have worked on bugs related to zc.buildout support, and it seems that now everything works fine. Thanks for those who try it on their side ! So we will be shipping a 0.6.5 probably friday for that, and postpone all the other issues for 0.6.6, except a few ones that are easy to tackle now. This version will also contaon the code that lakes sure we don't step on any Setuptools 0.7.x toes. If you have one issue you want to see fixed in 0.6.5, speak up. buildouters, if you want to try the latest dev version you can grab : http://python-distribute.org/bootstrap_dev.py Once 0.6.6 is proven to be working fine with zc.buildout, I'll change on zc.buildout side the bootstrap.py script as suggested, by adding a "--distribute" option so people can choose the tool they want to use. Thanks Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与

2 1

Future namespace support
by Lennart Regebro 15 Oct '09

15 Oct '09

2009/10/14 kiorky <kiorky(a)cryptelium.net>: >> This may be quite current even if it's not a good habit to have circular >> dependencies between distributions. >> Imagine that. >> >> B(0.7) -> A(0.6). >> A(0.6) -> B(0.7). I don't think that's a problem, although I can't see why you would need it in this case. >> Can i have the same namespace "ns" shared between the twice distributions with >> both the setuptools namespaces implementation (A) and the pkg_util's one (B)? I don't see why not, they would work the same way. Possibly the global _namespace_packages dictionary needs to be shared by both setuptools and the new module, but that can easily be handled by importing it from setuptools if setuptools is installed. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64

3 17

Re: [Distutils] Future namespace support
by P.J. Eby 15 Oct '09

15 Oct '09

At 04:55 PM 10/14/2009 +0200, Lennart Regebro wrote: >2009/10/14 kiorky <kiorky(a)cryptelium.net>: > > That's not what said the PEP (IOW what i had understood of) > >Oh, you don't *use* it the same way, no, but I assumed that the >internal mechanisms would be similar. Maybe I was wrong. You can use as many namespace package mechanisms as you want, simultaneously, as long as they're not all being used for the same namespace package. Bear in mind that the true mechanism of nsp's is simply a module's __path__ object; pkgutil and pkg_resources simply provide utilities for setting the __path__ appropriately. With PEP 382, the utilities become unnecessary, except for backward compatibility, and if you want to do fixup of a __path__ when sys.path is changed. However, as long as each nsp is only registered with one such utility, there should be no conflicts.

3 3

Re: [Distutils] [buildout] RFC: buildout support for distribute
by P.J. Eby 13 Oct '09

13 Oct '09

At 10:27 PM 10/13/2009 +0200, Tarek Ziadé wrote: >On Tue, Oct 13, 2009 at 10:07 PM, P.J. Eby <pje(a)telecommunity.com> wrote: > >> Ok sure, makes sense. We will return 'distribute' only if 'setuptools' > >> is from the 0.6.x series > >> and below. > > > > Great. I assume that means you plan to incorporate any further bug fixes > > that land in 0.6c10 (or, gods forbid, c11) in the release where this change > > is made. > >Yes, as long as we are able to spot them in your commits / issue >trackers changes. > >The latest commit you've made in setuptools package is still cryptic >to us because >it fixes many things at once. Sorry about that, but it was pretty much the only way to get it done in a weekend, without the overheads of separate commit messages, doc changes, and backporting killing me. Those overheads were the main reason I wasn't making changes more often; I dreaded the amount of work involved. Also, as it happened, I was able to fix multiple problems with single changes this way. >We were able to backport the sandbox violation but that's it at this point. The __getstate__/__setstate__ stuff in pkg_resources is also sandbox support; it makes it possible to keep working_set changes by recursive builds from corrupting the parent build's working set. I also expect it to support a "reset pkg_resources" API in 0.7a1 -- a long-requested feature. > > For versions you don't support emulating, I strongly suggest > adding an error > > of some kind, since actually *installing* setuptools with Distribute still > > present on sys.path would cause a problem. > >It is still unclear to me where this exception has to be thrown >since some APIs >in WorkingSet can be used just to check things out. > >I am guessing WorkingSet.resolve and parse_requirements are enough, but that's >just from the zc.buildout use case. One thing you could possibly do is capture Distribution.insert_on(), which would allow you to detect that setuptools is about to be added to a working set. Still another is that you could install a distribute.pth that puts Distribute on the path first, since 'distribute.pth' is alphabetically before 'easy-install.pth' and 'setuptools.pth'. (I'm not suggesting these are complete or risk-free solutions, of course.)

1 0

Re: [Distutils] [buildout] RFC: buildout support for distribute
by P.J. Eby 13 Oct '09

13 Oct '09

At 09:53 PM 10/13/2009 +0200, Tarek Ziadé wrote: >2009/10/13 P.J. Eby <pje(a)telecommunity.com>: > > At 09:25 PM 10/13/2009 +0200, Tarek Ziadé wrote: > >> > >> Notice that the current trunk of Distribute is now changing any > >> 'setuptools' > >> requirement that is tiggered using "Requirement.parse" and "resolve" APIs > >> into > >> a 'distribute' one. > > > > Please note that this change will cause problems for people in the future, > > as new features are introduced in the 0.7a1 line. The earlier version of > > this hack, which only ignored requests for older versions of setuptools, > > would not have caused such a problem. > > > > I would suggest that Distribute should only silently ignore requests for > > versions of setuptools that it can explicitly emulate; other > requests should > > result in an error, so that a problem cannot pass silently. > > > > Otherwise, a package depending on new features in the 0.7 line > will silently > > fail when those features are not present in its operating environment. > >Ok sure, makes sense. We will return 'distribute' only if 'setuptools' >is from the 0.6.x series >and below. Great. I assume that means you plan to incorporate any further bug fixes that land in 0.6c10 (or, gods forbid, c11) in the release where this change is made. For versions you don't support emulating, I strongly suggest adding an error of some kind, since actually *installing* setuptools with Distribute still present on sys.path would cause a problem.

2 1

Re: [Distutils] [buildout] RFC: buildout support for distribute
by P.J. Eby 13 Oct '09

13 Oct '09

At 09:25 PM 10/13/2009 +0200, Tarek Ziadé wrote: >Notice that the current trunk of Distribute is now changing any 'setuptools' >requirement that is tiggered using "Requirement.parse" and "resolve" APIs into >a 'distribute' one. Please note that this change will cause problems for people in the future, as new features are introduced in the 0.7a1 line. The earlier version of this hack, which only ignored requests for older versions of setuptools, would not have caused such a problem. I would suggest that Distribute should only silently ignore requests for versions of setuptools that it can explicitly emulate; other requests should result in an error, so that a problem cannot pass silently. Otherwise, a package depending on new features in the 0.7 line will silently fail when those features are not present in its operating environment.

2 1

Re: [Distutils] distribute and buildout: best practices?
by P.J. Eby 13 Oct '09

13 Oct '09

At 02:51 PM 10/13/2009 -0400, Jim Fulton wrote: >Really the run-time >code needed to support namespace packages should be split out into a >separate package and eventually added to the standard library. Are you volunteering? ;-) Seriously, MvL's namespace package PEP (#382) already takes care of most everything that's needed. With it in place, the only advantage of setuptools' approach is the ability to add more items to a package __path__ after it's already imported. (i.e., the fixup feature.) I heartily approve of that PEP, in case it's not obvious. I'd love to see it in Python 2.7, and will happily add support for it in setuptools 0.7.

2 1

[buildout] RFC: buildout support for distribute
by Jim Fulton 13 Oct '09

13 Oct '09

I plan to add explicit buildout support for distribute. Here's a sketch. Basically it boils down to satisfying requirements for setuptools with distribute whenever distribute is in buildout's working set. So, when installing a package that requires setuptools, it will convert that requirement to a requirement for distribute. There will be 2 separate bootstrap scripts, one that uses distribute and one that uses setuptools. There will also be a buildout configuration option that will allow a buildout configuration author to fix which is used. Probably: use-distribute = true This will only serve as a check that the right bootstrap was used. Comments? Jim -- Jim Fulton

3 4

dev versions
by Ian Bicking 13 Oct '09

13 Oct '09

So after creating, say, version 0.3.1, I always mark a package as 0.3.2dev. But this is annoying, you might never create a version 0.3.2 (e.g., 0.4 might be the next level). So, it would be better to use something like 0.3.1~dev. What is considered best practice for this? Ideally something that works with both Setuptools and the upcoming Distribute version spec. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker

14 17

Setuptools 0.6c10 release imminent; please test
by P.J. Eby 13 Oct '09

13 Oct '09

I've just updated the setuptools trunk and branch with a large number of bug fixes, preparing to release 0.6c10. These fixes include fixes for all the setuptools bugs currently marked "in-progress" or "testing" on the setuptools bug tracker as of this moment, and I'd like your help in ensuring that the new version is ready for release. Major updates and fixes include: * Fix for Vista UAC errors running easy_install.exe or other "installer-looking" executables * Fix for errors launching 64-bit Windows Python * Fix for the Python 2.6.3 build_ext API change * Support for the most recent Sourceforge download link insanity * Support for SVN 1.6 * Stop crashing on certain types of HTTP error * Stop re-trying URLs that already failed retrieval once * Fixes for various dependency management problems such as looping builds, re-downloading packages already present on sys.path (but not in a registered "site" directory), and randomly preferring local -f packages over local installed packages * Prevent lots of spurious "already imported from another path" warnings (e.g. when pkg_resources is imported late) * Ensure C libraries (as opposed to extensions) are also built when doing bdist_egg * Fixed running the "test" command under Python 2.6+ (0.7a1 trunk only) Other changes: * Misc. documentation fixes * Improved Jython support * Fewer warnings under Python 2.6+ * Warn when 'packages' uses paths instead of package names (because it causes other problems, like spurious "already imported" warnings) * Stop using /usr/bin/sw_vers on Mac OS (replaced w/'platform' module calls) You can install the updated version using easy_install (or pip!), asking for setuptools==dev (for the 0.7a1 trunk) or setuptools==dev06 (for the 0.6c10 development branch). But before you do that, be sure to uninstall Distribute completely. In particular, please note that these changes are NOT a merge from Distribute; upon review, many of the tracker-submitted patches used as a basis for forking were incorrect, incomplete, introduced new bugs, or were not addressing the root causes. (E.g., one of the changes I made fixes three superficially unrelated issues in the setuptools bug tracker.) Even if some of the change descriptions are the same in Distribute, many of the fixes are implemented quite differently.

11 14

Distribute and setuptools: what are the differences
by Michael Whapples 13 Oct '09

13 Oct '09

Hello, I realise I may be starting something I would prefer not to (looking at some of the replies of the announcement of setuptools 0.6c10), so I would like to ask that this tries to stay as a factual thing rather than a "having a go at the other". As it seems that setuptools is not "dead" just possibly a bit slow at being updated, could I ask what are the aims of the various projects setuptools and distribute (please try and keep this information restricted to your project and what it aims to do)? It would be nice to have this information as at the moment its a bit unclear what either really are trying to offer over the other. I would like to be able to make a fully informed choice on why use one over the other, I feel at the moment this isn't possible. I have to say from my view (as a developer of my own packages only using setuptools/distribute to help package my packages) that it currently looks a horrible mess, distribute tries to replace setuptools and does it in such a way that any package which specifically wants setuptools has to use distribute if another package wants it, so not allowing the one which specifically wants setuptools to get the latest setuptools (eg. now or soon it will be setuptools 0.6c10). It is tempting for me to use distutils and create my own custom code to give the features I currently really use from setuptools/distribute until this "mess" has been cleaned up. I know this idea of going a custom route doesn't really help things, but my main concern is my package and if no solution currently can satisfy me it is suitable then unfortunately custom solutions may be the best option for me (I won't support a mess). Michael Whapples

6 9

Problem with distribute and converting tests for python3
by Michael Whapples 12 Oct '09

12 Oct '09

Hello, Firstly thanks to those working on distribute, I had been using setuptools but was getting annoyed with it slowly developing (eg. not having python3 support, etc), so distribute seems like it is what I am looking for. Any way I am using distribute for one of my packages now (I wanted to try and support python3) but have noticed something which doesn't work for me. I have my main package sources in one directory and then tests in another directory (it makes it easy to separate them out when creating a binary package). Now this works fine for python2.x as I can include the tests in a source distribution by using MANIFEST.in, but it doesn't work for python3 as distribute doesn't seem to run 2to3 on them (although they are run by the distribute/setuptools test command in the setup.py script). When I looked at the distribute documentation the example there has the tests in a subpackage of the main package. So my question is, am I structuring my source distribution wrongly, is there a better way to do this which would work with distribute? If I were to structure my source distribution like the distribute example then how do I ensure unit tests aren't included in a binary distribution? Is there anyway I can get distribute to pick up my tests as I currently have my source distribution structured? Michael Whapples

3 8

Re: [Distutils] PEP 390 - new format from setup.cfg
by Stanley A. Klein 12 Oct '09

12 Oct '09

On Mon, October 12, 2009 12:24 am, Tarek Ziad? <ziade.tarek(a)gmail.com> wrote: ------------------------------ > > Message: 2 > Date: Mon, 12 Oct 2009 00:17:10 +0200 > From: Tarek Ziad? <ziade.tarek(a)gmail.com> > To: distutils-sig(a)python.org > Subject: [Distutils] PEP 390 - new format from setup.cfg > Hey > > this is the PEP for setup.cfg, as requested : > http://www.python.org/dev/peps/pep-0390 > > Please comment, > > Tarek > It isn't clear in the new format how one would set up a bdist_rpm for an SE-Linux system (such as Fedora or Centos) that has required pyc and pyo files to be included in the package. In the past this has been done using entries in setup.cfg. Stan Klein

1 0

distribution packaging from Distribute
by Rakotomandimby Mihamina 12 Oct '09

12 Oct '09

Hi all, Would you know a tutorial on Debian packaging from buildout/distribute? I mean: - I setup the buildout.cfg - I run buildout with Z or X option - I get the package I dont mind if it's not entirely Debian compatible (python and some libs duplication). Any link? Thank you. -- Architecte Informatique chez Blueline/Gulfsat: Administration Systeme, Recherche & Developpement +261 34 29 155 34

3 7

distribute or Distribute
by Reinout van Rees 12 Oct '09

12 Oct '09

I'm probably overlooking it somewhere in the documentation: should I specify a distribute dependency as "distribute" or "Distribute"? I'm used to lowercase so that's what I'm using till now, but I've spotted a Capital Letter somewhere... So which one is preferred? Reinout -- Reinout van Rees - reinout(a)vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com "Military engineers build missiles. Civil engineers build targets"

2 1

Eggs vs bdist_wininst (Was: Distutils and Distribute roadmap (and some words on Virtualenv, Pip))
by Paul Moore 11 Oct '09

11 Oct '09

2009/10/9 Michael Foord <fuzzyman(a)voidspace.org.uk>: > Many Windows users would be quite happy if the standard mechanism for > installing non-source distributions on Windows was via the wininst binaries. Actually, my understanding is that easy_install is perfectly able to use (download, unpack and install) bdist_wininst packages. So *as a binary distribution format* bdist_wininst installers can do all that eggs can, plus extra (install themselves unassisted!) So why is there a need for an egg binary format on Windows? Paul.

3 4

Re: [Distutils] [Python-Dev] Bits-of-Distribute naming
by Fred Drake 11 Oct '09

11 Oct '09

On Fri, Oct 9, 2009 at 12:08 PM, Chris Withers <chris(a)simplistix.co.uk> wrote: > distutils.entrypoints would seem to be the sensible place. Why's that? On the whole, I don't think entry points are specific to building & bundling, which is what distutils is all about. Entry points are about packages being able to provide metadata about how parts of them can be used. I'd rather see a pkgutil.entrypoint module with APIs for this. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller

3 2

PEP 376 unclarity about function of INSTALLER
by Carl Meyer 11 Oct '09

11 Oct '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, PEP 376 contains this line, regarding the INSTALLER metadata: "This allows a third-party application to use the uninstall function and make sure it's the only program that can remove a distribution it has previously installed." This sentence seems misleading to me. "We're all consenting adults here" and whatnot; it's not really possible for an installer to "make sure it's the only program that can remove a distribution it has previously installed." At best it is providing strong guidance. Perhaps replace "make sure it's the only program that can remove" with "strongly suggest that no other program remove"? Carl -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFK0i9H1j/fhc23WEARAoHrAKCv0EBG5HrjiSxBxJkNga8zmKmJTQCgtp1m RrLsw0+7LA1MHBqfYN+Vk9c= =nPHV -----END PGP SIGNATURE-----

2 1

Packaging Distribute
by Akira Kitada 11 Oct '09

11 Oct '09

Hi, I'm planning to make a port for Distribute to make it more accessible to users. However, thinking about up coming 0.7 release, which will break the compatibility with setuptools, I started wondering it's not so easy to make a package for distribute. If I understand correctly, Distutils 0.7 is like Python 3.x in some ways. It breaks compatibility and 0.7 and 0.6 both will continue to be developed in parallel at least a year or so. That sounds great but we can't have two versions of a Python module at the same time. Take a Jinja and Jinja2 for example. It has to have different names to make both package available at the same systen at the same time. For Distribute, there would be a few options to work around this: 1) Make 0.6 and 0.7 different package, like Distribute and Distribute2 (Jinja like solution) 2) Make 0.7 fat package, which includes 0.6(setuptools compat) features as deprecated. *) YOUR IDEAS COME HERE. Is there anyone having any other solutions? And what actually Distribute developers are thinking about this problem? # I heard Gentoo provides Distribute as setuptools but I think it's rather rude Thanks in advance.

12 17

Distribute 0.6.4 released !
by Tarek Ziadé 10 Oct '09

10 Oct '09

Hello On behalf of the Distribute team I am happy to announce the release of Distribute 0.6.4. - This release is now compatible with zc.buildout, as long as you use the special bootstrap.py file provided at nightly.ziade.org/bootstrap.py - A new upload_docs command to easily upload project documentation to PyPI's http://packages.python.org was added. As a matter of fact, Distribute documentation is now available at : http://packages.python.org/distribute - A bug was fixed in the bootstraping process (IOError: Could not build the egg) The release is available at PyPI, together with the installation instructions: http://pypi.python.org/pypi/distribute The next release in the 0.6.x will continue the work on fixing bugs (see http://bitbucket.org/tarek/distribute/issues) Regards Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与

1 0

[issue87] [PATCH] Python 3 support
by Phillip J. Eby 10 Oct '09

10 Oct '09

New submission from Phillip J. Eby <pje(a)telecommunity.com>: Copy of issue 56; see file 35 for patch ---------- messages: 378 nosy: lregebro, pje, pjenvey priority: wish status: chatting title: [PATCH] Python 3 support _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue87> _______________________________________________

1 0

[issue86] [PATCH] python setup.py test in python2.6
by Phillip J. Eby 10 Oct '09

10 Oct '09

New submission from Phillip J. Eby <pje(a)telecommunity.com>: Copy of issue 56 ---------- messages: 374 nosy: lregebro, pje, pjenvey priority: bug status: chatting title: [PATCH] python setup.py test in python2.6 _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue86> _______________________________________________

1 0

Re: [Distutils] [Python-Dev] Bits-of-Distribute naming
by Floris Bruynooghe 09 Oct '09

09 Oct '09

On Fri, Oct 09, 2009 at 06:05:50PM +0200, Tarek Ziadé wrote: > On Fri, Oct 9, 2009 at 5:42 PM, Chris Withers <chris(a)simplistix.co.uk> wrote: > > Tarek Ziadé wrote: > >> > >> - The code is splitted in many packages and might be distributed under > >> several distributions. > >> > >> - distribute.resources: that's the old pkg_resources... > > > Why not just call it pkg_resources and/or merge it with pkgutil to get it > > into the python stdlib? > > Because "pkg_resources" belongs to 0.6 and we want 0.7 to be > installable alongside 0.6 if needed. [...] > > Why not call in "pypi.client" and "pypi.server" or, better yet, get it into > > the stdlib as disutils.index.client distutils.index.server? > > We are keeping a "distribute." namespace for all bits. > > Now maybe one day it'll make it into Distutils, yes. But not now. If the final plan is (or might be) to move distribute.resources into the stdlib might it not ease transition to pick an import name that will be able to remain the same? Regards Floris PS: Moved discussion from python-dev to distutils-sig, hope that's fine. -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org

1 0

Re: [Distutils] [Python-Dev] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
by Ian Bicking 09 Oct '09

09 Oct '09

Probably all these discussions are better on distutils-sig (just copying python-dev to note the movement of the discussion) On Fri, Oct 9, 2009 at 11:49 AM, Michael Foord <fuzzyman(a)voidspace.org.uk> wrote: >> Outside of binaries on Windows, I'm still unsure if installing eggs >> serves a useful purpose. I'm not sure if eggs are any better than >> wininst binaries either...? > > Many Windows users would be quite happy if the standard mechanism for > installing non-source distributions on Windows was via the wininst binaries. > > I wonder if it is going to be possible to make this compatible with the > upcoming distutils package management 'stuff' (querying for installed > packages, uninstallation etc) since installation/uninstallation goes through > the Windows system package management feature. I guess it would be > eminently possible but require some reasonably high level Windows-fu to do. As far as pip works, it unpacks a package and runs "python setup.py install (and some options that aren't that interesting, but are provided specifically by setuptools)". Well, it's slightly more complicated, but more to the point it doesn't install in-process or dictate how setup.py works, except that it takes some specific options. Running a Windows installer in the same way would be fine, in that sense. Alternately pip could unpack the wininst zip file and install it directly; I'm not sure if that would be better or worse? If wininst uses the central package manager of the OS then certain features (like virtualenv, PYTHONHOME, --prefix, etc) would not be possible. For Distribute (or Setuptools or by association pip) to see that a package is installed, it must have the appropriate metadata. For Setuptools (and Distribute 0.6) this is a directory or file, on sys.path, "Package.egg-info" (or in Package-X.Y.egg/EGG-INFO). If a file, it should be a PKG-INFO file, if a directory it should contain a PKG-INFO file. So however the package gets installed, if that metadata is installed then it can be queried. I don't think querying the Windows system package management would be necessary or desirable. Nobody is trying that with deb/rpm either. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker

1 0

Re: [Distutils] [Python-Dev] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
by kiorky 09 Oct '09

09 Oct '09

I'm crossposting to continue on distutils. Ian Bicking a écrit : > On Fri, Oct 9, 2009 at 3:54 AM, kiorky <kiorky(a)cryptelium.net> wrote: > Well, if multi-versioned installs were deprecated, it would not be > necessary to use Setuptools' style of script generation. Instead you > could simply dereference the entry point, calling the underlying > function directly in the script. This detail is probably more of a > distutils-sig question, and I don't have a strong opinion. > > But I was thinking specifically of the egg activation buildout puts at > the top of scripts. The egg activation is just the result of the constructed working set, which aggregates all the python packages that fulfill the options inputed by the user. The only needed packages and nothing else or more. >>> began development, probably things would have gone this way. I think >>> it would make the environment more pleasant for buildout users. Also >> * I don't think so, buildout is the only tool atm that permit to have really >> reproducible and isolated environments. Even, if you use the pip freezing >> machinery, it is not equivalent to buildout, Control! > > I believe that to fully insulate buildout you need still virtualenv > --no-site-packages. But I'm not arguing that virtualenv/pip makes Right, I do so, but i also drop nothing in that virtualenv site-packages. > buildout obsolete, only that they have overlapping functionality, and > I think buildout would benefit from making use of that overlap. recipes have more features and are another way to do, complementary or not. (patching, compiling options, pinning version). You have also more control on what is installed/used/shared with buildout than with the others. >> * Buildout can have single part to construct required eggs, at a specific >> version and let you control that. Pip will just search for this version, see >> that it's not available and fail. You have even recipes (like >> minitage.recipe.egg that permit to construct eggs with special version when you >> apply patches onto, thus, you can have the same egg in different flavors in the >> same eggs cache available for different projects. Those projects will just have >> to pin the right version to use, Control!. > > In my own work I use multiple virtualenv environments for this use > case, to similar effect. pip of course is not a generalized build > tool, but then minitage.recipe.egg is not the main egg installer > either. *.recipe.egg can use caches to avoid duplications among many projects environments. You setup seems to duplicate stuff around. >> * Another thing is the "funny script generation", you have not one global >> site-packages for your project, but one global cache. But from this global >> cache, your scripts will only have available the eggs you declared, see Control! >> * Moreover buildout is not only a python packages manager, it's some of its >> recipes that permit to use it as. Buildout is just a great deployment tool that >> allow to script and manage your project in a "funny" and "flexible" way, Control! > > Sure; I'm just advocating that buildout more explicitly use some of > the functionality of virtualenv/pip (which may require some more > features in those tools, but I'm open to that). But specific > discussion of this would probably be more appropriate on > distutils-sig. > -- -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF

1 0

Re: [Distutils] [Python-Dev] excluding site-packages with buildout/virtualenv
by Chris Withers 09 Oct '09

09 Oct '09

[moved to disutils-sig] Ian Bicking wrote: > Well, if multi-versioned installs were deprecated, it would not be > necessary to use Setuptools' style of script generation. Instead you > could simply dereference the entry point, calling the underlying > function directly in the script. This detail is probably more of a > distutils-sig question, and I don't have a strong opinion. > > But I was thinking specifically of the egg activation buildout puts at > the top of scripts. Not sure what you mean by this last bit... > I believe that to fully insulate buildout you need still virtualenv > --no-site-packages. buildout has a --no-site-packages option (hopefully also specifiable in the [buildout] section) and some other cool things that I believe Gary Post worked on lurking on a branch waiting for Jim to review... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

1 0

[buildout] hard coded urls considered harmful
by Chris Withers 09 Oct '09

09 Oct '09

Hi All, bootstrap.py contains the following hard coded url: exec urllib2.urlopen('http://peak.telecommunity.com/dist/ez_setup.py' ).read() in ez With hindsight, this seems like a bad idea. For example, with the ridiculous situation we currently have with setuptools and distribute. It also means that the above url can't ever change, which is a bit of a harsh requirement. My suggestion would be for bootstrap.py to include the code in ez_setup.py, but that seems a little heavyweight. I guess this will all be solved when the standard library includes modules to download packages from PyPI and install them. But what to do in the meantime? cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

3 5

ANN: ActivePython 2.6.3.7 (and PyPM) is now available
by Sridhar Ratnakumar 09 Oct '09

09 Oct '09

I'm happy to announce that ActivePython 2.6.3.7 is now available for download from: http://www.activestate.com/activepython/ This is a patch-level release that updates ActivePython to core Python 2.6.3 along with the fixes for a couple of critical regressions that instigated the work on 2.6.4. See the release notes for full details: http://docs.activestate.com/activepython/2.6/relnotes.html Introducing PyPM ---------------- This release includes a new packaging tool by activestate called Python Package Manager (PyPM). PyPM - currently in beta - is the package management utility for ActivePython. It simplifies the task of locating, installing, upgrading and removing Python modules. For full details, see: http://docs.activestate.com/activepython/2.6/pypm.html Here's a sample command line output:: $ pypm install lxml Get: [pypm.activestate.com] :repository-index: Ready to perform these actions: The following packages will be installed: lxml-2.2.2 Get: [pypm.activestate.com] lxml 2.2.2-1 Installing lxml-2.2.2 $ python >>> import lxml.etree >>>^D $ pypm remove lxml Ready to perform these actions: The following packages will be removed: lxml-2.2.2 Removing lxml-2.2.2 $ pypm install pylons Ready to perform these actions: The following packages will be installed: pastescript-1.7.3 formencode-1.2.2 weberror-0.10.1 simplejson-2.0.9 routes-1.11 nose-0.11.1 mako-0.2.5 past edeploy-1.3.3 pylons-0.9.7 tempita-0.4 webtest-1.2 beaker-1.4.2 webhelpers-0.6.4 paste-1.7.2 pygments-1.1.1 decorator-3.1.2 webob-0.9.6.1 Get: [pypm.activestate.com] formencode 1.2.2-1 Get: [pypm.activestate.com] nose 0.11.1-1 [...] Get: [pypm.activestate.com] decorator 3.1.2-1 Get: [pypm.activestate.com] webob 0.9.6.1-1 Installing formencode-1.2.2 Installing weberror-0.10.1 [...] Installing pygments-1.1.1 Fixing script /home/sridharr/.local/bin/pygmentize Installing decorator-3.1.2 What is ActivePython? --------------------- ActivePython is ActiveState's binary distribution of Python. Builds for Windows, Mac OS X, Linux, HP-UX and AIX are made freely available. ActivePython includes the Python core and the many core extensions: zlib and bzip2 for data compression, the Berkeley DB (bsddb) and SQLite (sqlite3) database libraries, OpenSSL bindings for HTTPS support, the Tix GUI widgets for Tkinter, ElementTree for XML processing, ctypes (on supported platforms) for low-level library access, and others. The Windows distribution ships with PyWin32 -- a suite of Windows tools developed by Mark Hammond, including bindings to the Win32 API and Windows COM. See this page for full details: http://docs.activestate.com/activepython/2.6/whatsincluded.html As well, ActivePython ships with a wealth of documentation for both new and experienced Python programmers. In addition to the core Python docs, ActivePython includes the "What's New in Python" series, "Dive into Python", the Python FAQs & HOWTOs, and the Python Enhancement Proposals (PEPs). An online version of the docs can be found here: http://docs.activestate.com/activepython/2.6/ We would welcome any and all feedback to: ActivePython-feedback(a)activestate.com Please file bugs against ActivePython at: http://bugs.activestate.com/query.cgi?set_product=ActivePython On what platforms does ActivePython run? ---------------------------------------- ActivePython includes installers for the following platforms: - Windows/x86 - Windows/x64 (aka "AMD64") - Mac OS X - Linux/x86 - Linux/x86_64 (aka "AMD64") - Solaris/SPARC - Solaris/x86 - HP-UX/PA-RISC - AIX/PowerPC - AIX/PowerPC 64-bit Extra Bits ---------- ActivePython releases also include the following: - ActivePython26.chm: An MS compiled help collection of the full ActivePython documentation set. Linux users of applications such as xCHM might find this useful. This package is installed by default on Windows. Extra bits are available from: http://downloads.activestate.com/ActivePython/etc/ Thanks, and enjoy! The Python Team -- Sridhar Ratnakumar sridharr at activestate.com

3 4

Re: [Distutils] how to easily consume just the parts of eggs that are good for you
by Stanley A. Klein 09 Oct '09

09 Oct '09

On Wed, April 9, 2008 10:05 pm, Greg Ewing <greg.ewing(a)canterbury.ac.nz> wrote: > Message: 4 > Date: Thu, 10 Apr 2008 12:59:39 +1200 > From: Greg Ewing <greg.ewing(a)canterbury.ac.nz> > Subject: Re: [Distutils] how to easily consume just the parts of eggs > that are good for you > To: distutils-sig(a)python.org > > Paul Moore wrote: > >> I believe that Mac OS X goes for an even simpler structure - >> applications store *everything* in the one directory, so that >> install/uninstall is simply a directory copy/remove. > > Yep, and thereby cuts the whole gordian knot, throws the > pieces on the fire and burns them. :-) > > Package managers have always seemed to me to be an > excessively complex solution to a problem that needn't > have existed in the first place. > > I keep hoping that someday Linux will support something > like MacOSX application bundles and frameworks, but I > haven't seen any sign of it yet. > I think this discussion arises because the operating systems we are dealing with are based on very different concepts. Windows and Mac are fundamentally single user systems that have added capabilities for multiple users and are intended to be used with proprietary software. Those considerations lead to minimal dependencies among packages (each proprietary provider needs to control its own package, except for the OS), individual users serving as their own sysadmins, and similar factors. Any dependencies in the proprietary software are hidden from the user because the provider has compiled the dependencies into the binary code they supply. Unix/Linux are fundamentally multi-user systems with a distinct role for a sysadmin. Linux and the BSD's are intended to be used with Free/Open Source Software (FOSS), and Unix originated the Software Tools concept in which individual, relatively simple, separately-developed tools are combined to perform complex tasks. Both FOSS and the Software Tools concept encourage dependencies. The need for package managers arises out of the Unix FHS. If you look at the FHS, it is clearly designed to simplify the job of the sysadmin in a multi-user system that uses FOSS and Software Tools. For example, deciding what to backup and how often to do it in a Unix/Linux system is relatively easy for the sysadmin. All the installed software is in certain top-level directories. All the config files are in /etc. All the logs. caches, spools, web pages, process locks, and certain other data are in /var. All the user data is in /home or its sysadmin-determined equivalents. If the sysadmin needs space, deleting files in /tmp will not cause a problem. In summary, Python is being used on systems that have very different underlying OS use cases. To some extent, the natural use case for Python is closest to that of Linux/Unix. Running Python on Windows/Mac requires adapting for those platforms some of the kinds of tools that simplify operations on Linux/Unix systems. This discussion is essentially about how far that goes, how to accomplish it, and how to remain compatible with the existing tools on Linux/Unix. Stan Klein

4 4

tracking requested vs dependency installs in PEP 376 metadata
by Carl Meyer 08 Oct '09

08 Oct '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey all, I propose adding a bit to the PEP 376 metadata that indicates whether a package was installed by user request or as a dependency of another package. This would allow (un)installer tools to intelligently remove orphaned dependencies, if they so choose. There might be questions about the details of such an uninstaller feature, but I'm not intending to discuss that here. The metadata itself is simple enough to track, and seems like it ought to be included for its future usefulness. I propose adding a metadata file REQUIRED within the .egg-info directory. The presence of this file indicates that the user specifically required this distribution. The absence of the file indicates that the distribution was installed as a dependency. The contents of the file are not used. For the API, I propose adding a "required" property to the Distribution class, which would be True or False based on the presence or absence of the REQUIRED file. I've added a demo implementation to a fork of Tarek's pep376 repo on bitbucket: http://bitbucket.org/carljm/pep376/changeset/0c8002e65cb7/ Thoughts? Carl -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFKzhZa1j/fhc23WEARApy3AJ0bbzHBaS85dURlRDEcQOHlrgovXgCg022F OkpQ56+Re1yRnoNFfFNYm88= =nkMB -----END PGP SIGNATURE-----

1 0

Distutils 0.6.4 this week
by Tarek Ziadé 07 Oct '09

07 Oct '09

Hello, We are going to ship Distribute 0.6.4 by the end of this week with a few more bugs fixed, whereas they were listed in Setuptools tracker (http://bitbucket.org/tarek/distribute/wiki/bug_listing) whereas they were added directly in our tracker. If you had any issue you want to see fixed in this release, please speak up. If you want to help, you can install and play with the nightly build of 0.6.4 by running: http://nightly.ziade.org/distribute_setup_dev.py Last, a new wiki page has been added where we are giving more details on the roadmap for 0.6.x and 0.7.x : http://bitbucket.org/tarek/distribute/wiki/roadmap Regards Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与

2 1

Re: [Distutils] Package install failures in 2.6.3 - setuptools vs Distribute
by Ronald Oussoren 07 Oct '09

07 Oct '09

On Monday, 05 October, 2009, at 11:53AM, "Lennart Regebro" <regebro(a)gmail.com> wrote: >2009/10/5 Jeff Rush <jeff(a)taupro.com>: >> Very unfortunate, as in, it should NOT have happened. And *especially* >> without any announcement on python.org or mention on the >> python-committers list of something this major. > >Well "this major"... It's a bug fix that breaks a setuptools monkey-patch. >But yes, it was discovered before release, and maybe it should have >been discussed, I'm not on python-dev anymore. I agree with Jeff that this shouldn't have happened, or should at the very least have been documented in the release notes for 2.6.3. I know of several users of Python that have been bitten by this (they installed 2.6.3 and now easy_install doesn't work anymore for them). For beginners this issue is a showstopper that they cannot resolve without help. > > >> Distribute is very new and there are many folk who will not be adopting >> it until it has been out for quite some time. > >Nobody will adopt it until they are forced to. This unfortunate bug >means people are forced to quicker than expected. I don't think that's >an actual problem. This is a problem, it means 2.6.3 is not a simple drop-in replacement for 2.6.2 but requires the replacement of another component as well. That can be a problem in organizations with strict configuration management where you cannot install new software without going to lots of red tape (and that might involve lawyers when you install a new package instead of upgrading an existing one). Ronald

15 28

Re: [Distutils] Package install failures in 2.6.3 - setuptools vs Distribute
by P.J. Eby 06 Oct '09

06 Oct '09

At 11:53 AM 10/5/2009 +0200, Lennart Regebro wrote: >2009/10/5 Jeff Rush <jeff(a)taupro.com>: > > Very unfortunate, as in, it should NOT have happened. And *especially* > > without any announcement on python.org or mention on the > > python-committers list of something this major. > >Well "this major"... It's a bug fix that breaks a setuptools monkey-patch. Subclassing distutils commands != monkeypatching. If, say, numpy's distutils extensions subclass build_ext and override that method, they could have had the same problem. Same for anybody else's distutils extensions.

3 3

Distribute install problem on Snow Leopard
by Ralf Gommers 06 Oct '09

06 Oct '09

Hi, I installed Distribute on a Snow Leopard box using the default Python that comes with OS X. I used the installation method recommended in the docs, the distribute_setup.py script. Now easy_install fails no matter what package I try to install (it does not get around to looking for the name of the requested package): $ easy_install blablabla Traceback (most recent call last): File "/usr/bin/easy_install-2.6", line 10, in <module> load_entry_point('setuptools==0.6c9', 'console_scripts', 'easy_install')() File "/Library/Python/2.6/site-packages/distribute-0.6.3-py2.6.egg/pkg_resources.py", line 281, in load_entry_point return get_distribution(dist).load_entry_point(group, name) File "/Library/Python/2.6/site-packages/distribute-0.6.3-py2.6.egg/pkg_resources.py", line 2197, in load_entry_point raise ImportError("Entry point %r not found" % ((group,name),)) ImportError: Entry point ('console_scripts', 'easy_install') not found Did I forget something, or is this a bug? Any suggestions on how to fix it? Cheers, Ralf

2 5

[ANN] stdeb 0.3.2 and 0.4.1
by Andrew Straw 06 Oct '09

06 Oct '09

stdeb produces Debian source packages from Python packages via a new distutils command, sdist_dsc. Automatic defaults are provided for the Debian package, but many aspects of the resulting package can be customized via a configuration file. An additional command, bdist_deb, creates a Debian binary package, a .deb file. stdeb: http://github.com/astraw/stdeb This email announces releases 0.3.2 and 0.4.1. release 0.4.1 download: http://pypi.python.org/pypi/stdeb/0.4.1 release 0.3.2 download: http://pypi.python.org/pypi/stdeb/0.3.2 Release 0.4.1 adds new features, conveniences and bug fixes to the recently released, but unannounced 0.4 release. These two releases move stdeb to use debhelper 7 (and therefore require at least Ubuntu Intrepid, Debian Lenny, or the use of backports). This use of debhelper 7 allows the auto-generated debian/rules file to be greatly simplified. stdeb 0.4 also switches to python-support from pycentral. If you do not need to migrate packages from earlier versions of stdeb, it is recommended to use the "--pycentral-backwards-compatibility=false" command-line argument. See the changelog[1] and release notes[2] for more information. [1] http://github.com/astraw/stdeb/blob/release-0.4.1/CHANGELOG.txt [2] http://github.com/astraw/stdeb/blob/release-0.4.1/RELEASE_NOTES.txt Release 0.3.2 (and the unannounced 0.3.1) are maintenance releases for the old-stable branch, which works with older distributions such as Ubuntu Hardy. These releases added the bdist_deb command. See the changelog[3] for more information. [3] http://github.com/astraw/stdeb/blob/release-0.3.2/CHANGELOG.txt As always, the venue for discussion of stdeb is the distutils mailing list at http://mail.python.org/mailman/listinfo/distutils-sig Thanks to all who have helped stdeb for these and previous releases: Authors ------- * Andrew Straw <strawman(a)astraw.com> * Pedro Algarvio, aka, s0undt3ch <ufs(a)ufsoft.org> * Gerry Reno (initial bdist_deb implementation) Additional Credits ------------------ * Zooko O'Whielacronx for the autofind-depends patch * Brett (last name unknown) for the --ignore-install-requires patch * Ximin Luo for a bug fix * Alexander D. Sedov for bug fixes and suggestions * GitHub for hosting services. * WebFaction (aka python-hosting) for previous hosting services. -Andrew

2 2

distutils: packaging a generated configuration file
by Mark Dickinson 05 Oct '09

05 Oct '09

I'm trying to use distutils for the first time to package up a project, and struggling a bit; I wonder whether some kind soul could point me in the right direction. I'm packaging a pure Python project that uses ctypes. The only complication is that I'd like the setup script to install a configuration file alongside the various .py files. From the documentation, this sounds like something that would usually be specified with 'package_data' or 'data_files'. The catch is that parts of the configuration file are generated at setup time: that is, the setup script gathers various pieces of system information (e.g., library locations) and uses those to transform a hard-coded 'config.in' file into the 'config' file that I want to install. I could just generate the 'config' file in the top-level package directory, but it seems dangerous to assume that that directory is writable; it seems better to use one of the build directories that distutils already knows about. What's the best way to manage generation and installation of the config file? I've got as far as subclassing the build command and making __run__ create the config file from the config.in file, putting it into the build_temp directory; I can't figure out how to tell distutils to install it in the right place. It seems like I want a sort of build_data/install_data pair of commands, that allows creation and installation of *generated* data files. Any hints? Mark

2 1

Re: [Distutils] Package install failures in 2.6.3 - setuptools vs Distribute
by P.J. Eby 05 Oct '09

05 Oct '09

At 06:53 PM 10/5/2009 +0200, Lennart Regebro wrote: >Possibly if you somehow >think it's the Distribute teams fault that a bugfix in Python ended up >breaking setuptools. If it would have been better not to fix that bug, >then the blame reasonably goes to the Python core developers, not the >Distribute team. In this case, though, the "Python core developer" is also the Distribute lead. (i.e., it was Tarek who made the changes to the distutils.) So it's a bit understandable that some people might wonder if there was a conflict of interest. I don't personally think that's the case; it's pretty much inevitable that the distutils making progress means other things will break. But it's easy to see how others might take the situation another way, or treat it as an example of Distribute policy towards backward compatibility, or of what kind of breakage is considered acceptable in a dot release. It would be good to bear in mind that extending the distutils (or setuptools) is *not* monkeypatching; both libraries provide explicit assurance that subclassing is in fact allowed. And there's nothing all that special about setuptools' subclassing of build_ext; in fact, if you look back in the archives here, other people have done equivalent subclassing to support dynamic library building. I haven't checked their code, but there is a strong possibility that it would also fail in the same way. This is not really about monkeypatching, or about special support for setuptools.

2 1

Re: [Distutils] Package install failures in 2.6.3 - setuptools vs Distribute
by P.J. Eby 05 Oct '09

05 Oct '09

At 07:53 PM 10/5/2009 +0200, Hanno Schlichting wrote: >If I understand the comments on this ticket correctly, Tarek has >changed distutils in a way so the last setuptools release continues >to work, correct? Yes. And a very nice fix, done quite quickly. Thank you Tarek. >So based on the current state of Python 2.6.4 will work again with >an unmodified setuptools 0.6c9? AFAICT, that is correct.

2 1

Re: [Distutils] Package install failures in 2.6.3 - setuptools vs Distribute
by P.J. Eby 05 Oct '09

05 Oct '09

At 04:57 PM 10/5/2009 +0200, Lennart Regebro wrote: >2009/10/5 Barry Warsaw <barry(a)python.org>: > > I apologize for my part in this, but moving forward I think that if it's > > possible to patch and release a setuptools that works with Python 2.6.3 > > /and/ earlier Python 2.6.x's, then that should happen asap. > >PJE seems interested in this, as he asked about a patch, so maybe. I expect to have a small amount of time later this week to work on setuptools. No guarantees, but this is certainly one of the bugs on my short list for doing something with. > > If that's not possible, then we might need to revert the distutils > > change in a quick Python 2.6.4. > >That would be a big mistake. Actually, I think the mistake here is where non-bugfix code was ported from 3.x back to the 2.6.x maintenance branch. I'm particularly concerned about the .compiler / ._compiler change, as it seems to me to be responsible for breaking mingw32 compilation on Windows, but I haven't had time to investigate thoroughly. (It actually looks like a problem that might be in Python 3 as well.)

1 0

how to build location-independent bdist packages on OS X?
by Bill Janssen 05 Oct '09

05 Oct '09

I'm trying to bundle up a Python package with a C extension in it for Python 2.6 on an OS X 10.6 system. I don't want to install it in the normal /Library/Python/2.6/site-packages/ location. But when I try "python setup.py bdist", it builds a tar file with the prefix /Library/Python/2.6/site-packages as a prefix to each file. I then tried "python setup.py bdist_dumb" with the same result. I then tried "python setup.py bdist --prefix=.", but "--prefix" isn't recognized by bdist. What's the appropriate magic here? Oh, and I don't want to have to use setuptools. TIA, Bill

1 0

Re: [Distutils] Package install failures in 2.6.3 - setuptools vs Distribute
by P.J. Eby 04 Oct '09

04 Oct '09

At 03:49 PM 10/3/2009 +0200, Tarek Ziadé wrote: >Notice that this has been fixed in Ubuntu already with a patched >version of setuptools Is the patch or an equivalent already in the setuptools tracker? And if not, can someone please post it there? Thanks.

2 1

[issue85] setuptools builds of extension modules fail with Python 2.6.3
by Ned Deily 04 Oct '09

04 Oct '09

New submission from Ned Deily <nad(a)acm.org>: A change in distutils distributed with Python 2.6.3 breaks setuptools. Builds of extension modules fail with n get_ext_filename ext = self.ext_map[fullname] KeyError: '<xx>'. An analysis and patch is documented in the Distribute tracker issue 41: http://bitbucket.org/tarek/distribute/issue/41/ ---------- messages: 357 nosy: nad priority: critical status: unread title: setuptools builds of extension modules fail with Python 2.6.3 _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue85> _______________________________________________

1 0

Get install prefix for module at runtime
by Wolodja Wentland 04 Oct '09

04 Oct '09

Hi all, i am pretty new to distutils (since yesterday) and am struggling with accessing installed data_files. I want to ship a library that benefits from some data_files from another package. My wishes: * distribution should go in 'PREFIX/lib/foo' (site-packages?) * datafiles should go in 'PREFIX/share/foo' * Access to data files from modules My question is: "How to reliably access data files from a module in foo?" A thorough explanation follows. If you can answer the aforementioned question just think tl;dr and skip it ;-) Installation Schemes ==================== There seem to be three different installation schemes regarding setting of this PREFIX. The following examples assume installation of package 'foo' which contains module 'bar' and data file 'baz.data'. Default install (setup.py install) ----------------------------------------- * Packages installation path: 'sys.prefix/lib/pythonX.Y/site-packages/' * Data files installation path: 'sys.prefix/share/' That means that in the aforementioned example the following file system structure will be created upon installation: Package: /usr/lib/python2.5/site-packages/foo/bar.py Data: /usr/share/foo/baz.data Home scheme (setup.py install --home=HOME) --------------------------------------- * Packages installation path: 'HOME/lib/python' * Data files installation path: 'HOME/share/' Resulting structure: Package: HOME/lib/foo/bar.py Data HOME/share/foo/baz.data Prefix scheme (setup.py --prefix=PREFIX) * Package installation path: 'PREFIX/lib/pythonX.Y/site-packages' * Data installation path: 'PREFIX/share/' Resulting structure (for PREFIX==/usr/local) Package: /usr/local/lib/python2.5/site-packages/foo/bar.py Data: /usr/share/foo/baz.data Finding Data files ================== My problem is finding a reliable way to access the data files from within bar.py. Approach 1 - using module.__file__ ---------------------------------- bar_path_elements = bar.__file__.split(os.path.sep) prefix = os.path.join( os.path.sep, *itertools.takewhile(lambda el: el != 'lib')) data_file_path = os.path.join(prefix, 'share', 'foo') * Will this work reliably? * What if the user specifies a different data directory with '--install-data' ? Approach 2 - writing a build.py file at installation time --------------------------------------------------------- The last question made me think, that Approach 1 works for the three standard installation schemes, but fails miserably if the user decides to do anything fancy. As i do not comprehend all the options you can give to 'setup.py install' or know about them i am not sure if there are not many more problems hidden in there. The solution seems to be to create a build.py file that includes this information at installation time and access the data there. My problem is just: HOW? I tried with the following setup.py script, but am unsure how to access the correct options: --- snip --- # -*- coding: UTF-8 -*- #!/usr/bin/env python from __future__ import with_statement from distutils.core import setup import sys import getopt def create_build_file(): try: opts, args = getopt.getopt(sys.argv[1:], "", []) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ What to do here???? except getopt.GetoptError, err: pass with open('lib/mwdb/build.py', 'w') as build_fp: #build_fp.write('# -*- coding: UTF-8 -*-\n') #build_fp.write("LIB_PREFIX = '%s'\n"%(options.lib_prefix)) #build_fp.write("DATA_PREFIX = '%s'\n"%(options.data_prefix)) #build_fp.write("EXEC_PREFIX = '%s'\n"%(options.exec_prefix)) try: if 'install' == sys.argv[1]: create_build_file() except IndexError: pass setup(name='foo', version='0.1', packages=['foo'] package_dir = { '':'lib' }, ... ) --- snip --- The problem i am facing now is: How to parse the options? Do I really have to recreate the complete distutils option parsing logic - and probably fail? All that without optparse! How can i get the aforementioned options? Is the file creation way the correct way to handle this? I really don't know what to do now and am also wondering why nobody had that problem before! Are all other libraries shipped with external data buggy for some installation schemes? How is this normally solved? with kind regards and thanks for reading all this Wolodja Wentland

3 9

stdeb-0.3 error
by Gerry Reno 03 Oct '09

03 Oct '09

sudo easy_install stdeb # brought in stdeb 0.3 $ cd myappdir # where my setup.py is located $# following http://github.com/astraw/stdeb/ quickstart 1 $ python -c "import stdeb; execfile('setup.py')" sdist_dsc && \ > cd `find deb_dist -mindepth 1 -maxdepth 1 -type d` && \ > dpkg-buildpackage -rfakeroot -uc -us && \ > cd ../.. && > echo ".deb created successfully in deb_dist/" Traceback (most recent call last): File "<string>", line 1, in <module> File "setup.py", line 41, in <module> sys.path.append(os.path.join(os.path.abspath(os.path.dirname(__file__)), "bin")) NameError: name '__file__' is not defined ========================================================= The error is coming from the setup.py line: import imp import sys import os import glob from distutils.core import setup, Command from distutils.command.install import install if os.name == 'nt': import py2exe sys.path.append(os.path.join(os.path.abspath(os.path.dirname(__file__)), "bin")) =========================================================== I do not get this error when I run setup.py normally for other commands like 'sdist'. How can I fix this? Regards, Gerry

7 86

Problem using zc.recipe.cmmi to build Python
by Kent Tenney 03 Oct '09

03 Oct '09

Howdy, In pursuit of a buildout for my core environment, I try the following: [python-2.6.3] recipe = zc.recipe.cmmi url = http://www.python.org/ftp/python/2.6.3/Python-2.6.3rc1.tgz ... make fails with ImportError: No module named cStringIO because ./configure creates a Modules/Setup which says #cStringIO cStringIO.c if I uncomment that line the make is fine. I haven't found a way to tell $:./configure or $:make to do that, zc.recipe.cmmi doesn't seem to provide a hook between configure and make. If someone can tell me to fix this with options or environment I'm done. If not, I welcome advice on alternatives to zc.recipe.cmmi, (which I would consider the 'standard' solution.(darn you Shuttleworth for co-opting the word 'canonical' :-))) - comb through the many xx.xx.cmmi recipes (without a sense of associated quality or support level) - pick a xx.xx.command recipe and write a part which does what I want - write my own 'recipe.build-interp' Thanks, Kent

2 2

Clarification asked wrt FAQ "How does Distribute interacts with virtualenv?"
by Roger Erens 03 Oct '09

03 Oct '09

Hi Tarek e.a., thanks for the nice documentation for Distribute on Pypi. There are however a few more things that are not so clear to me in the virtualenv-FAQ: "How does Distribute interacts with virtualenv?" Typo: interacts -> interact "Everytime you create a virtualenv it will install setuptools, so you need to re-install Distribute in it right after. The Distribute project will not attempt to patch virtualenv so it uses it when globally installed." There are a few too many "it"s in those sentences to my taste. Is this meant: "Everytime you run virtualenv, it will install setuptools in the created virtualenv directory, so you need to install Distribute in that directory right after. (First activating the virtualenv)."? And "The Distribute project will not attempt to patch virtualenv, so [the virtual environment?] uses [the setuptools installed within the virtual environment?] when [Distribute? is [only]] globally installed."? "Once installed, your virtualenv will use Distribute transparently." explicitly this is: "Once Distribute is installed in your virtualenv, your virtualenv will use Distribute transparently."? "Although, if you have Setuptools installed in your system-wide Python, and if the virtualenv you are in was generated without the --no-site-packages option, the Distribute installation will stop." stop -> stop installing? "You need in this case to build a virtualenv with the --no-site-packages option or to install Distribute globally." Maybe it might also be noted that there's a virtualenv-distribute (by Florian Schulze) hanging around somewhere on the web. Hope this helps to improve the documentation, Roger

2 1

compiling psycopg2 with zc.recipe.egg: allowing custom build_ext options?
by Kevin Teague 01 Oct '09

01 Oct '09

Regarding Chris recent thread on doing some hair pulling while getting psycopg2 to install, I recently added this distribution to a buildout with the following configuration: [versions] pscopg2 = 2.0.8 [buildout] parts = app postgresql init-pgsql pgsql-symlinks psycopg2 find-links = http://initd.org/pub/software/psycopg/PSYCOPG-2-0/ versions = versions # app is a Grok-based application that requires pscopg2 [app] recipe = zc.recipe.egg eggs = ${psycopg2:egg} gsc.docsdb z3c.evalexception>=2.0 Paste PasteScript PasteDeploy interpreter = python-console # PostgreSQL parts [psycopg2] recipe = zc.recipe.egg:custom egg = psycopg2 include-dirs = ${postgresql:location}/include library-dirs = ${postgresql:location}/lib [postgresql] recipe = zc.recipe.cmmi url = http://wwwmaster.postgresql.org/redir/198/h/source/v8.3.7/postgresql-8.3.7.… extra_options = --with-readline [init-pgsql] recipe = iw.recipe.cmd on_install = true on_update = false cmds = ${postgresql:location}/bin/initdb -D ${postgresql:location}/var/data -E UNICODE [pgsql-symlinks] recipe = cns.recipe.symlink symlink_target = ${buildout:directory}/bin symlink_base = ${postgresql:location}/bin symlink = clusterdb createdb createlang createuser dropdb droplang dropuser ecpg initdb ipcclean pg_config pg_controldata pg_ctl pg_dump pg_dumpall pg_resetxlog pg_restore postgres postmaster psql reindexdb vacuumdb This builds a complete PostgreSQL install inside the project directory. Of course, if you've already got a preferred postgres install, you can simplify this quite a bit and just point the include- dirs and library-dirs to that location. I did find that I had to pin psycopg2 down to 2.0.8, since it didn't seem to work with 2.0.10. But looking a bit further into this issue, the preferred way to build psycopg2 is to supply the full path to pg_config as a build_ext. However, zc.recipe.egg:custom only supports a fixed list of build_ext options. Is this a feature or a bug? e.g. Is there any reason why it wouldn't be possible to support arbitrary build_ext options with this recipe? Or is there another egg-building recipe out there which supports this? By patching a local copy of zc.recipe.egg to allow the pg_config build_ext option, I was able to use this part to compile psycopg2: [psycopg2] recipe = zc.recipe.egg:custom egg = psycopg2 pg_config = ${buildout:bin-directory}/pg_config Which worked fine for the latest release, 2.0.10, of psycopg2. (also, as a bonus 'Arg!', note that it's necessary to supply a custom find-links URL to buildout, since the PyPI page for psycopg2 has bogus download links)

2 1

No announcement for 0.6.3?
by Roger Erens 01 Oct '09

01 Oct '09

Hi, distribute-0.6.3 was uploaded to Pypi on 09-27-09, but no announcement of its availability was made? Cheers, Roger

2 1

something else to throw into the static metadata mix
by Chris Withers 01 Oct '09

01 Oct '09

Hi All, Sorry to bring this up if it makes things more difficult, if it's been solved or is covered by existing proposals, please point me in the right way. I've had a bit of a torrid time building psycopg2 from source of late, and in my dream world, being able to specify psycopg2 as a dependent egg would "just work" and pull down the right statically linked binary egg. This raises a problem that I haven't seen covered anywhere: not only would these eggs have to be platform dependent, they'd also need to be dependent on the required version of postgres. Does setuptools/buildout/any other existing or proposed packaging solution cater for this kind of requirement? cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

8 15