Mailman 3 August 2013 - Distutils-SIG

help requested getting existing project "gv" into PyPI
by Jess Austin 15 Aug '13

15 Aug '13

hi, I recently suggested that the "gv" package be added to PyPI. This is a close-to-C Graphviz port distributed by the Graphviz graph visualization project. They currently distribute this package in source, and in rpms, debs, and the equivalents of those for Windows, Mac, and Solaris. It seemed only natural that a small entry in PyPI be added so that "pip" would be able to install this package in a straightforward way (i.e., without using "git" references etc). The issue tracker url for this suggestion: http://www.graphviz.org/mantisbt/view.php?id=2324 As you can see at that link, the maintainer had some difficulty when trying to create the project through the web form, culminating in a "Not found()" error message. I unfortunately don't have a great deal of insight into this, but I thought someone on this list might be able to help. Alternatively, please tell me if I'm making an unreasonable suggestion. It was my understanding that "pip" is able to find installable files from even quite rudimentary PyPI entries, even if they're hosted elsewhere. However, if that's not the case, and the PyPI entry would require extensive ongoing interaction from the "gv" maintainers, then this probably isn't going to work. thanks, Jess

2 2

PEP440 and fork versioning
by Marcus Smith 14 Aug '13

14 Aug '13

I'm wondering if PEP440 should recommend how to version forks? It's fairly common to fork dependencies temporarily until the change can be released upstream. Ideally, you want to version a fork (and keep the same name) so that it fulfills the requirement, but be obvious that it's a fork. Although pip allows overriding requirement consistency, consistency is preferred, and needed in cases where a `pkg_resources.require` enforces it in a console script. As it is now, the "post-release" scheme works for this, but it's not the intended use case. Marcus

2 4

Last PEP 426 update for a while
by Nick Coghlan 10 Aug '13

10 Aug '13

I pushed a version of PEP 426 with an initial sketch of an entry points replacement design: http://hg.python.org/peps/rev/ea3d93e40e02 To give it a sensible home in the PEP, I ended up defining "modules" and "namespaces" fields in addition to "commands" and "exports". The overall section is called "Installed interfaces". I initially tried it with the unpacked multi-field mapping for export specifiers, but ended up reverting to something closer to the setuptools notation for readability purposes. For the moment, "requires_extra" is included since it isn't that hard to explain. The other two major additions to the PEP are a note near the top explaining that the expected time frame for metadata 2.0 is post Python 3.4 release and a caveat on the build system description explaining that we know it isn't ready for prime-time yet. I wanted to get this part up so anyone tinkering with wrapper scripts had at least a preliminary scheme to work from, but as per the note on time frames, I don't consider the details of PEP 426 to be an urgent topic for further discussion unless/until it directly impacts next generation tools like Warehouse and distlib. Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

3 10

Unexpected VersionConflict
by Townsend, Scott E. (GRC-RTM0)[Vantage Partners, LLC] 10 Aug '13

10 Aug '13

During easy_install of an egg where two versions of pyparsing were available (1.5.2 and 1.5.6), a VersionConflict was raised: pkg_resources.VersionConflict: (pyparsing 1.5.6 (/usr/lib/python2.7/dist-packages), Requirement.parse('pyparsing==1.5.2')) This was unexpected since sys.path (via virtualenv) has version 1.5.2 before 1.5.6. And the system gets 1.5.2 from 'import pyparsing', not 1.5.6. I've traced this to the line calling _sort_dists(dists), line 801 in my copy of pkg_resources.py: def __getitem__(self,project_name): """Return a newest-to-oldest list of distributions for `project_name` """ try: return self._cache[project_name] except KeyError: project_name = project_name.lower() if project_name not in self._distmap: return [] if project_name not in self._cache: dists = self._cache[project_name] = self._distmap[project_name] _sort_dists(dists) return self._cache[project_name] The problem is that one dependent package of the egg has a requirement of 'pyparsing' while a subsequent dependent package has a requirement of 'pyparsing==1.5.2'. The intent was that by using virtualenv with a correct sys.path version 1.5.2 would be used for both requirements. Unfortunately, because of the call to _sort_dists(), the 'pyparsing' requirement is resolved to 1.5.6 by env.best_match() in WorkingSet.resolve(). Once that resolution was made, the more explicit requirement fails. Note that without the _sort_dists() call the egg loads and runs correctly, using pyparsing 1.5.2. Its not clear to me that removing the _sort_dists() call is correct in general, but it appears to be a bug that an egg which would load and run correctly reports a VersionConflict.

3 5

Problem uploading SCons package to pypi. Receiving 403 You are not allowed to edit 'scons' package information
by William Deegan 08 Aug '13

08 Aug '13

Greetings, I apologize in advance if this is the wrong place for this. I've filed a support ticket and a bug request at the following locations: https://bitbucket.org/pypa/pypi/issue/49/upload-failed-403-you-are-not-allo… http://sourceforge.net/p/pypi/support-requests/285/ Here's the summary of the problem. The SCons project maintainer has been changed from Steven Knight (knight) to Gary Oberbrunner(garyo) and myself (William Deegan (bdbaddog)) The appropriate (I believe) roles have been added to Gary and my accounts: https://pypi.python.org/pypi?:action=role_form&package_name=SCons (We're both marked Owner). I updated my setup.py to indicate that I'd be packaging and tried: python setup.py --verbose sdist upload --show-response Which yields: …. Creating tar archive removing 'scons-2.3.0' (and everything under it) running upload Using PyPI login from /Users/bdbaddog/.pypirc Submitting dist/scons-2.3.0.tar.gz to http://pypi.python.org/pypi Upload failed (403): You are not allowed to edit 'scons' package information The last package uploaded to pypi is ancient and we'd like to put a current version there. Can anyone either correct the permissions and/or point us to what we're doing wrong? Thanks, Bill

1 0

pip 1.4.1 and virtualenv 1.10.1 released
by Donald Stufft 08 Aug '13

08 Aug '13

We've released pip 1.4.1 and virtualenv 1.10.1. One major change is both of these releases are signed with My GPG key instead of Jannis's. pip 1.4.1 (2013-08-07) ------------------------------- * **New Signing Key** Release 1.4.1 is using a different key than normal with fingerprint: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA * Fixed issues with installing from pybundle files (Pull #1116). * Fixed error when sysconfig module throws an exception (Pull #1095). * Don't ignore already installed pre-releases (Pull #1076). * Fixes related to upgrading setuptools (Pull #1092). * Fixes so that --download works with wheel archives (Pull #1113). * Fixes related to recognizing and cleaning global build dirs (Pull #1080). virtualenv 1.10.1 (2013-08-07) ------------------------------------------ * **New Signing Key** Release 1.10.1 is using a different key than normal with fingerprint: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA * Upgraded pip to v1.4.1 * Upgraded setuptools to v0.9.8 ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

1 0

What to do about the PyPI mirrors
by Richard Jones 07 Aug '13

07 Aug '13

Hi all, I've just been contacted by someone who's set up a new public mirror of PyPI and would like it integrated into the mirror ecosystem. I think it's probably time we thought about how to demote the mirrors: - they cause problems with security (being under the python.org domain causes various issues including inability to use HTTPS and cookie issues) - they're no longer necessary thanks to the CDN work So, things to do: - links and information on PyPI itself can be removed - tools that use mirrors still need to be able to but mention of using public mirrors is probably something to demote These are just rough thoughts that occurred to me just now. Richard

13 58

How to disable PYTHONPATH checking when installing packages using distribute
by lukshuntim＠gmail.com 06 Aug '13

06 Aug '13

Hi, During installing a package which uses distribute (matplotlib in this case), it refuses to work with this message "running install Checking .pth file support in /usr/local/stow/matplotlib-1.3.0/lib/python2.7/site-packages/ /usr/bin/python -E -c pass TEST FAILED: /usr/local/stow/matplotlib-1.3.0/lib/python2.7/site-packages/ does NOT support .pth files error: bad install directory or PYTHONPATH ... Please make the appropriate changes for your system and try again." I install local packages using the stow approach, which installs each package under its own sub-directory and later "stowed" (https://www.gnu.org/software/stow/). Such "error" becomes a nuisance as a different PYTHONPATH has to be set for each installation of a package. How can the checking be disable? I don't seem to be able to find anything in the documentation and would be grateful for any pointer. Or maybe it's better turned into a warning and users be reminded to add the install directory to PYTHONPATH. Regards, ST --

2 1

New PyPI mirror in China
by Hexchain Tong 06 Aug '13

06 Aug '13

Hi, We have set up a new PyPI mirror in China. Location: Wuhan, Hubei, China Bandwidth: 100Mbps connected to CERNET(AS4538) URL: http://pypi.hustunique.com/ Mirror homepage: http://mirrors.hustunique.com/ Contact email: it+pypi(a)hustunique.com We use bandersnatch to synchronize every 5 minutes. Please add us to the official mirror list. Thanks! Regards, Hexchain Tong -- IT Service Team at Unique Studio, HUST

3 4

setuptools' install_script overwrites symlinked files rather than replacing symlinks
by Michał Górny 06 Aug '13

06 Aug '13

Hello, We've got a pretty specific setup where various Python scripts in /usr/bin are symlinked to a common wrapper. For example: /usr/bin/easy_install -> python-exec As a result, calling 'setup.py install' in a package that installs setuptools' legacy script wrappers (e.g. setuptools itself) rewrites python-exec (which -- shortly saying -- breaks a lot) rather than replacing the 'easy_install' symlink. I believe that the core issue is in command/easy_install.py. There, the write_script() command writes directly onto the destination file with no precautions: if not self.dry_run: ensure_directory(target) f = open(target,"w"+mode) f.write(contents) f.close() Therefore, if 'target' is a symlink, the symlink target is opened rather than the expected path. distutils itself is free of this issue since it removes the target before writing (distutils/file_util.py): if os.path.exists(dst): try: os.unlink(dst) except os.error, (errno, errstr): raise DistutilsFileError( "could not delete '%s': %s" % (dst, errstr)) This suffers a race condition but is better than nothing. Other tools usually create a temporary file in the target directory and use rename() to atomically replace the target. I'm willing to write a patch. Please just tell me which solution would you prefer. (please keep python(a)g.o in CC when replying) -- Best regards, Michał Górny

2 1