Mailman 3 September 2010 - Distutils-SIG

Re: [Distutils] please fix easy_install shorter URL preference (Was: easy_install wrong download site preference)
by P.J. Eby 25 Sep '10

25 Sep '10

At 07:59 PM 9/18/2010 +0300, anatoly techtonik wrote: >On Sun, Sep 12, 2010 at 9:08 PM, P.J. Eby <pje(a)telecommunity.com> wrote: > > That issue was fixed in October 2009, so you are likely using something > > <0.6c11. > >I am using setuptools-0.6c11-py2.6.egg on Windows Vista. Oops. My bad - this was actually fixed only 7 months ago, in February 2010, and it's not in 0.6c11, only the nightly snapshots. To update your installation, run: easy_install -U setuptools This should give you 0.6c12dev-r_something_or_other. ;-) > > Note, however, that since the full source distribution *also* includes the > > python code, all that's needed is to change its setup.py slightly and move > > it to the root of the source tree. > >If the Python was the only code inside - that'd be acceptable, but it >seems like the proper fix lies in setuptools AI code. You do realize that asking everybody to update their version of setuptools in order to be able to install one particular package is a little unrealistic? I mean, *your* setuptools is at least seven months out of date, so even if I changed this, how long would it be till your users updated? ;-) In truth, I do have an idea that would actually fix this problem in the Google case (a change to the way the source is processed after extraction), but it will likely be a while before I can implement it, and a while further still before everyone has installed the update. (Note that 0.6c5 and 0.6c9 are still very popular versions, and 0.6c9 is like *two years* out of date.)

2 1

Re: [Distutils] Distribute error? datetimewidget.pot: File name too long
by P.J. Eby 24 Sep '10

24 Sep '10

At 05:13 PM 9/24/2010 +0200, Tarek Ziadé wrote: >On Fri, Sep 24, 2010 at 5:01 PM, P.J. Eby <pje(a)telecommunity.com> wrote: > > Have you tried it using plain setuptools (0.6c11 or greater)? There are > > some bugs in distribute regarding recursive build-time dependencies that > > were fixed in setuptools last October, but which are still outstanding in > > distribute. > >Please can you point us to the issue in the tracker and the commit >where that fix happened ? > >I'd be glad to fix it if this happens to be true. http://mail.python.org/pipermail/distutils-sig/2009-October/013823.html

2 1

Re: [Distutils] Distribute error? datetimewidget.pot: File name too long
by P.J. Eby 24 Sep '10

24 Sep '10

At 05:53 PM 9/24/2010 +0200, Tarek Ziadé wrote: >On Fri, Sep 24, 2010 at 5:20 PM, Jon Hadley <me(a)jon-hadley.com> wrote: > >> What precise package should I download from PyPI to try > >> myself on a fresh Distribute install ? > > > > http://pypi.python.org/pypi/fez.atcsv/0.2 > >I found the bug: every time a dependency is to be installed it's >recursively uncompressed in the previous tmp directory. So after a >while, you get dead long paths and get your bug. > >Working on a fix tonite. The real WTF here is that the same package is being repeatedly downloaded and installed as its own dependency repeatedly -- it's unlikely that fixing the temp directory processing will fix *that* problem, unless by some chance that accidentally makes the package recognize itself.

1 0

distribution name capitalisation considered important ; -)
by Chris Withers 24 Sep '10

24 Sep '10

Hi All, Looks like we have quite a consistent set of rules with regard to captilisation of package names on file systems where case isn't important, shame the same can't be said for distribution names. So, looks like case is important in package names. With distribution names, it becomes much more murky. Setuptools, and so all the ilk that use it, is happy to ignore case naming for distributions. To make matters worse, it also uses os.path.normcase on any distributions obtained from a Windows file system, which will *always* corrupt any distribution names that aren't all lower case already. These differences cause subtle problems in tools which attempt to pin versions of particular distributions. So, I guess I'm asking why we don't just say "distribution names are case sensitive" and be done with it? If the case of a requirement or distribution name is wrong, it would be good to get early failures rather than subtle and annoying bugs later on down the line. Of course, the horse is already bolted on this. The only "sane" option now would be for all distribution names to be lowercased by all tools all of the time. How do others feel about this? Chris

6 11

Re: [Distutils] easy_install command arguments not propagated when installing source distributions
by P.J. Eby 23 Sep '10

23 Sep '10

At 12:23 PM 9/23/2010 -0700, Jason R. Coombs wrote: >I understand the challenge here - setuptools is launching setup.py from the >source distribution for jaraco.compat, and setup.py doesn't accept >parameters for 'allow_hosts' and 'find_links'. Hm. This is actually a bit of a hole with respect to --allow-hosts. I'll have to see if there's a way to pass that information through (probably not as a setup.cfg file, though). >Is there any way that we can use source distributions in this environment >(without customizing each source distribution for the environment)? If not, >perhaps an improvement could be added to setuptools to populate a setup.cfg >file when installing source distributions to include the easy_install flags >supplied to the requiring install. In the meantime, one quick fix you could implement is to add a distutils.cfg to the Lib/distutils/ directory of your Python installation(s). If you want to do this in a (semi-)automated way, you can run this in any project source directory: python setup.py saveopts -g easy_install [options to save] This will save whatever options you give to the global config file for you.

1 0

easy_install command arguments not propagated when installing source distributions
by Jason R. Coombs 23 Sep '10

23 Sep '10

We're using easy_install 0.6c9 or greater. Our systems are behind a firewall with a custom cheeseshop. All required packages are available on the cheeseshop. However, we seem to be unable to install source distributions, because the dependencies specified in setup_requires aren't resolved with the parameters (allow-hosts and find-links) passed to easy_install. Here's a transcript of what happens (with #comments). (sandbox)jason.coombs@host:~/sandbox$ easy_install -mZ -H cheeseshop.company.com -f http://cheeseshop.company.com jaraco.compat Searching for jaraco.compat Reading http://cheeseshop.company.com Best match: jaraco.compat 0.1 Downloading http://cheeseshop.company.com/jaraco.compat-0.1.tar.gz Processing jaraco.compat-0.1.tar.gz # it found the source distribution, and now runs setup.py from it Running jaraco.compat-0.1/setup.py -q bdist_egg --dist-dir /tmp/easy_install-WMIHzo/jaraco.compat-0.1/egg-dist-tmp-XrEJAr # the source distribution specifies setup_requires="hgtools>=0.4" Searching for hgtools>=0.4 Reading http://pypi.python.org/simple/hgtools/ # it stalls here for a long time trying to reach a host which is not accessible due to the firewall Download error: (110, 'Connection timed out') -- Some packages may not be found! Couldn't find index page for 'hgtools' (maybe misspelled?) Scanning index of all packages (this may take a while) Reading http://pypi.python.org/simple/ # same thing - stalls a long time Download error: (110, 'Connection timed out') -- Some packages may not be found! No local packages or download links found for hgtools>=0.4 Best match: None Traceback (most recent call last): # details omitted AttributeError: 'NoneType' object has no attribute 'clone' # I think this is the error for "not found" when mercurial is present I understand the challenge here - setuptools is launching setup.py from the source distribution for jaraco.compat, and setup.py doesn't accept parameters for 'allow_hosts' and 'find_links'. Is there any way that we can use source distributions in this environment (without customizing each source distribution for the environment)? If not, perhaps an improvement could be added to setuptools to populate a setup.cfg file when installing source distributions to include the easy_install flags supplied to the requiring install. In other words, the command "easy_install -f http://foo.org -H foo.org source.package" would 1) Download the source package. 2) Expand it to a temporary directory. 3) Create or customize the setup.cfg for that package (or use --command and --option) to include dependency_links=['http://foo.org'] and an equivalent parameter with the same effect as allow_hosts. 4) Run setup.py as above. I'm not sure all of this is possible or even desirable. I appreciate any suggestions you may have on this scenario. I wouldn't be surprised too if someone's already encountered this, but I was unable to find any resources on it. If that's the case, please accept my apologies for repeating the question and direct me to the resource or search terms that will help me locate it. Much obliged, Jason

1 0

[issue117] Unable to upload package without storing password in ~/.pypirc
by Ted Tibbetts 21 Sep '10

21 Sep '10

New submission from Ted Tibbetts <intuited(a)gmail.com>: I can't seem to upload a source distribution without storing my password in ~/.pypirc. If I have no ~/.pypirc, and I give a the command ``$ python setup.py sdist register upload`` and then give my login credentials, this happens at the end: :: running register Password: Registering terminable_thread to http://pypi.python.org/pypi Server response (200): OK running upload Submitting dist/terminable_thread-0.7.tar.gz to http://pypi.python.org/pypi Upload failed (401): Incorrect password I get similar results if my ``~/.pypirc`` has a line in the ``[pypi]`` section containing just ``password:``, whether or not I omit the ``register`` command. I was able to upload the distribution by putting my password in ``~/.pypirc``. The ``upload`` command seems to be checking for the password independently from ``register``; this runs contrary to the documentation_. .. _documentation: http://docs.python.org/distutils/packageindex.html#pypirc I'm running the bona fide (not ``distribute``) ``setuptools``, version ``0.6c11``. This assertion is based on :: $ cat `which easy_install` | grep load from pkg_resources import load_entry_point load_entry_point('setuptools==0.6c11', 'console_scripts', 'easy_install')() and the fact that I just deleted my old ``setuptools`` and installed by executing the current tarball from the ``setuptools`` PyPI page. ---------- messages: 553 nosy: intuited priority: bug status: unread title: Unable to upload package without storing password in ~/.pypirc _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue117> _______________________________________________

3 2

[issue116] typo in command.bdist_enc.make_zipfile
by Ted Tibbetts 21 Sep '10

21 Sep '10

New submission from Ted Tibbetts <intuited(a)gmail.com>: Looks like there is a typo in the function `make_zipfile` in the file `command/bdist_enc`: the last line of the else clause of the if construct at the end of the function passes `file` as the third parameter to `visit`; it should be passing `files`, I think. Symptoms include the exception `TypeError("'instancemethod' object is not iterable")` when attempting to run `easy_install -n some_sdist.tar.gz`. Applying the attached patch seems to resolve the issue; I'm still not entirely sure what it's telling me, but at least it's not spitting out a stack trace. ---------- files: bdist_egg.py.diff messages: 550 nosy: intuited priority: bug status: unread title: typo in command.bdist_enc.make_zipfile Added file: http://bugs.python.org/setuptools/file72/bdist_egg.py.diff _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue116> _______________________________________________

2 1

Re: [Distutils] [issue116] typo in command.bdist_enc.make_zipfile
by P.J. Eby 21 Sep '10

21 Sep '10

At 03:10 AM 9/21/2010 +0000, Ted Tibbetts wrote: >Looks like there is a typo in the function `make_zipfile` in the >file `command/bdist_enc`: the last line of the else clause of the if >construct at the end of the function passes `file` as the third >parameter to `visit`; it should be passing `files`, I think. > >Symptoms include the exception `TypeError("'instancemethod' object >is not iterable")` when attempting to run `easy_install -n some_sdist.tar.gz`. > >Applying the attached patch seems to resolve the issue; I'm still >not entirely sure what it's telling me, but at least it's not >spitting out a stack trace. Hi Ted. It appears you are using distribute, not setuptools. Unfortunately, some Linux distributions are shipping distribute (a fork of setuptools) under the name "setuptools", which creates user confusion. If you are using your Linux distribution's installation of setuptools, please make sure to file this bug with your Linux distributor as well. Distribute has many changes relative to setuptools, some of which have introduced new bugs. It looks like this is the specific change that introduced the problem you're experiencing: http://bitbucket.org/tarek/distribute/changeset/512db2c962e4 In this case the problem is fairly minor, since it only affects dry runs that would probably fail later in the process anyway. Unless you are using Distribute by choice for its additional features, you may wish to uninstall it and replace it with a stable version of setuptools. (Unfortunately, if you are using your Linux distributor's installation of it, this may not be possible.)

1 0

Re: [Distutils] please fix easy_install shorter URL preference (Was: easy_install wrong download site preference)
by P.J. Eby 18 Sep '10

18 Sep '10

At 12:08 PM 9/12/2010 +0300, anatoly techtonik wrote: >https://sourceforge.net/apps/trac/halfcooked/ticket/29 > >Gerald is the second package from the last 4 months that I couldn't >install due to this very obscure behavior, and I suspect there are >more. Gerald installs fine when I try it, and from the same URL (which isn't the shortest in any case). I suspect you are not using the current version of easy_install, as the problem shown is due to Sourceforge's use of '/download' URLs. That issue was fixed in October 2009, so you are likely using something <0.6c11. (Or perhaps you are using distribute, which has still not applied this bug fix almost a year later.) >Phillip, could you, please, still run through your archives to success >in explaining why this logic of choosing a shorter download URL is >necessary? I'd really to see what packages benefit from it, It was originally added for PIL and other effbot-released packages; it's retained because to change it now would introduce random breakages to other projects, in order to benefit one whose source filenames are ambiguous anyway. >I believe Google protocol buffers popularity alone is enough to change >the behavior. Right now, the naming of the two source distributions is ambiguous, even for humans. Note, however, that since the full source distribution *also* includes the python code, all that's needed is to change its setup.py slightly and move it to the root of the source tree. (The changes needed would consist of adding 'package_dir={"":"python"}' to the setup() options, and changing relative path uses in the setup.py so that they don't assume the current directory is the 'python' subtree... i.e., mainly just changing all '../src' occurrences to 'src'.) In the alternative, calling the release that contains all languages 'protobuf-all-2.3.0.*' rather than 'protobuf' would also fix the issue.

2 1