Mailman 3 December 2010 - Distutils-SIG

The new MSI given by Python 2.7
by cool-RR 24 Dec '10

24 Dec '10

I'm making a release of my project today, and I noticed that the MSI created by Python 2.7 when doing `bdist_msi` does not seem to be attached to a specific Python version. Is it safe to supply it for users of Python 2.5-2.7? (My package is pure-Python.) When uploading to PyPI, I'm forced to choose a single Python version for the MSI. What do I do? I don't want people to be mislead to think that it's an MSI only for 2.6 when it works for 2.5-2.7. I tried uploading the same file for all three versions, but PyPI didn't allow this, telling me I already uploaded that file. Please help, I want to make a release today. Thanks, Ram.

3 4

Re: [Distutils] [issue119] setuptools-0.6c11.win32-py2.5 python path recognition problem
by P.J. Eby 23 Dec '10

23 Dec '10

At 05:39 AM 12/23/2010 +0000, hm wrote: >I have downloaded setuptools-0.6c11.win32-py2.5.exe and tried to >install it on Windows 7 (64 bit). I have an existing Python >installation. The setuptool recognizes the path, however, puts a >quote around the path. The problem is that it also carries the >quotes around the Python path in the installation directory and >makes a path like: > >"C:\Python25\"\Lib\site-packages\ > >This is an invalid path and in the next step the installer complains >that cannot install the files in the provided path. The setuptool >also does not allow editing this path. Any help is appreciated, asap. This sounds like a problem with the distutils installer for Windows. Have you tried installing any other Python .exe's from PyPI, and do they have the same problem?

1 0

[issue119] setuptools-0.6c11.win32-py2.5 python path recognition problem
by hm 23 Dec '10

23 Dec '10

New submission from hm <hmotahary(a)yahoo.com>: I have downloaded setuptools-0.6c11.win32-py2.5.exe and tried to install it on Windows 7 (64 bit). I have an existing Python installation. The setuptool recognizes the path, however, puts a quote around the path. The problem is that it also carries the quotes around the Python path in the installation directory and makes a path like: "C:\Python25\"\Lib\site-packages\ This is an invalid path and in the next step the installer complains that cannot install the files in the provided path. The setuptool also does not allow editing this path. Any help is appreciated, asap. Thank Hamid ---------- messages: 569 nosy: hm priority: bug status: unread title: setuptools-0.6c11.win32-py2.5 python path recognition problem _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue119> _______________________________________________

1 0

Buildout or distribute raise unnecessary version conflict?
by Alan Franzoni 20 Dec '10

20 Dec '10

Hello, I've got a strange issue with version resolution when using zc.buildout; I don't know if it's zc.buildout specific or it's caused by something which is done by distribute. The example code can be fetched from there: hg clone https://Alan@bitbucket.org/Alan/buildoutversionissue End of output result: Installing test. While: Installing test. Error: There is a version conflict. We already have: zope.testrunner 4.0.0 but asd 0.1.0 requires 'zope.testrunner==4.0.0b1'. If you check within the downloaded eggs, you'll see there's no egg requiring zope.testrunner 4.0.0; there's just zc.recipe.testrunner requiring "zope.testrunner", without any version. if egg A requires "foolib" while egg B requires "foolib==1.0.0", and the latest available version of foolib is "1.0.1", then a version conflict error will arise; it's just as if a "naked" egg dependency is pinned to the latest available version of a package. Is that an intended behaviour? I don't seem to find any evidence of that in distribute or distutils doc. Although specifying a dependency without a version shouldn't be a good practice, it seems quite common - mostly because many people have got full control of the pypi section on their own repo and they can decide what's offered there, so they just specify "mydependency" on their other projects. I think it's quite a wide assumption, by the way. Also, this is not the usualy way dependencies are resolved in most package managers. When using yum (and apt should be quite similar), something like that happens: Scenario: two versions of "mydep" are available: mydep 1.0.0 and 1.0.1 "foo" depends just on mydep "bar" depends on mydep 1.0.0 If I just want to install "foo", I'll get foo and mydep 1.0.1 on my system. But if I try installing both, I'll get foo, bar and mydep 1.0.0, because that will be resolved as the best way to handle all dependencies. Any comment? -- Alan Franzoni -- contact me at public(a)[mysurname].eu

3 8

'python setup.py test' in develop mode?
by Barry Warsaw 18 Dec '10

18 Dec '10

Something bugs me about virtualenv, distribute, development, and testing. I figure I'm probably doing something wrong and that y'all will be able to set me straight. I'm working on a new tool called pkgme[1]. It uses distribute and recommends using virtualenv for development. After activating the virtualenv you can do 'python setup.py develop' and do convenient in-place editing so that your changes to the source show up immediately in the running environment. So far so good. However, when I want to run the test suite, it does the equivalent of a 'python setup.py build' and then runs the tests out of the build/lib.{platform}-{version} directory. This actually screws with our tests because (at least currently) the tests are looking for shell scripts and other programs that live in our tree, but are not part of the Python packaging, so don't get built or installed by setup.py. When we do filesystem introspection to try to find the scripts to exec them, it will work when running in develop mode, but fail in the tests, since __file__ points into build/lib.* instead of the source tree. So I'm wondering if other folks have hit similar problems and what best practices can be recommended to deal with this problem. I can think of various hacks around the problem, but don't want to reinvent the wheel. Or do you think that 'python setup.py test' should use the in-place tree and this is Just A Bug? Cheers, -Barry [1] https://launchpad.net/pkgme

4 6

demo and setup.py
by Alessandro Dentella 18 Dec '10

18 Dec '10

Hi, i'm new to this list. I hope this question is pertinent to the list, if not please address me to a more appropriate one. I'd like to understand what is the preferred way to cope with demo examples/directory while packaging. I have a classic structure sqlkit-N.n/ sqlkit/ setup.py MANIFEST.in demo/ My goal would be to have a setup so that 'python setup.py sdist' would package also the demo, so that 'python setup.py sdist upload' could be all I need to do to publish it. Is this a reasonable goal? I ask this as I wouldn't know where to place the demo in the target installation. Under Linux that I know pretty well a demo would be under /usr/(local/)/share/doc... but where sould it be placed under Windows? Is this simething that should be taken care of by setuptools? Searching in the docs I never found the 'demo' word and google was not very usefull too. Any hint is appreciated. thanks a lot sandro -- Sandro Dentella *:-) http://www.reteisi.org Soluzioni libere per le scuole http://sqlkit.argolinux.org SQLkit home page - PyGTK/python/sqlalchemy

2 1

stdeb development?
by Sean Ochoa 16 Dec '10

16 Dec '10

Hello all. I'm wondering if there is still any effort behind the stdeb package development. I find it super handy for what I do at work, and I'm wondering if there's going to be canonical support and/or further package development done in this area. - Sean

3 2

Obtuse warning from pkg_resources when egg and non-egg distributions clash
by Arve Knudsen 15 Dec '10

15 Dec '10

Hello I've just been able to properly identify why pkg_resources at times issues an obtuse (to me at least) warning along these lines: "Module <module> was already imported from <filename>, but <egg> is being added to sys.path". It turns out that really that a non-egg distribution is on the module search path before a corresponding egg distribution. If you run bin/test.py in the attached case, you should see a demonstration of the issue. Right now, it bit me when testing under a continuous integration slave on a machine where the tested project is also installed as an egg. I couldn't for the life of me understand why this warning was being issued, when I couldn't see it on my development machine. Not before painstakingly debugging pkg_resources, did it dawn on me that pkg_resources only complained on the test machine since there was no egg metadata in the source tree (whereas in my development source tree there is). Until debugging pkg_resources I actually didn't know that a directory (i.e., with Python packages) is considered an egg if it has a .egg-info file (with egg metadata) in it. I just hadn't had the motivation yet to learn the egg technology that well. Considering that pkg_resources' rationale for issuing this warning is so difficult to derive from the message, may I suggest please that we modify the message somewhat for added clarity? If it were more explicit, it should be much easier to rectify the warning's cause. My suggestion is a message on this form: "'<egg>' is being added to sys.path, but contained module '<module>' was already imported from '<filename>'. Could this be a non-egg distribution?". From such a warning, it should be possible to derive that the module may have been imported from what is not considered by pkg_resources an egg distribution (such as a clean source tree). Thanks, Arve

1 0

Newbie - Buildout bootstrap error pkg_resources.DistributionNotFound: zc.buildout==1.5.2
by Cops Club 15 Dec '10

15 Dec '10

I'm a newbie to Python, so please be patient with me.... 1) On Ubunto 10.10 I used sudo to install python-setuptools then used easy_install to install zc.buildout. 2) I then logged on as a different user (who is not able to sudo) to create my first buildout project. plonesvc@ubuntu:~$ mkdir exercise1 plonesvc@ubuntu:~$ cd exercise1/ plonesvc@ubuntu:~/exercise1$ buildout init Creating '/home/plonesvc/exercise1/buildout.cfg'. Creating directory '/home/plonesvc/exercise1/bin'. Creating directory '/home/plonesvc/exercise1/parts'. Creating directory '/home/plonesvc/exercise1/eggs'. Creating directory '/home/plonesvc/exercise1/develop-eggs'. Generated script '/home/plonesvc/exercise1/bin/buildout'. 3) I downloaded the bootstrap.py from svn plonesvc@ubuntu:~$ wget \ http://svn.zope.org/*checkout*/zc.buildout/trunk/bootstrap/bootstrap.py 4)And tried to run the bootstrap - which failed: plonesvc@ubuntu:~/exercise1$ python bootstrap.py Downloading http://pypi.python.org/packages/2.6/s/setuptools/setuptools-0.6c11-py2.6.egg Traceback (most recent call last): File "bootstrap.py", line 256, in <module> ws.require(requirement) File "/tmp/tmpCfYQ3c/setuptools-0.6c11-py2.6.egg/pkg_resources.py", line 666, in require File "/tmp/tmpCfYQ3c/setuptools-0.6c11-py2.6.egg/pkg_resources.py", line 565, in resolve pkg_resources.DistributionNotFound: zc.buildout==1.5.2 5) I've tried searching for the error via google without success. 6) I have subsequently installed virtual env and setup a new buildout project and run the bootstrap.py successfully. Which, is great but I want to know why I wasn't able to do this without virtual env? I was wondering if someone could explain why step 4 above failed. What was the reason for this? Simon

2 1

Re: [Distutils] How to best install pkg_resources?
by Laura Creighton 15 Dec '10

15 Dec '10

Arve: You may find that Bento already does what you want. http://cournape.github.com/Bento/ Laura Creighton

2 1