Re: [Distutils] PyPI Download Counts
anatoly techtonik techtonik at gmail.com writes: I'd say that not getting access to download stats from the start is a fail on the side of PSF or whoever involved in coordination with Fastly. There are many CDN providers out there and I suspect so far only Fastly was contacted. The primary responsibility of that coordinator is correctly sending the message for CDN provider that PyPI is a public exhibition of their service quality, and not a tax exemption for charity. I'd say Fastly should be interested to help with making us download stats exposed in a convenient API friendly way, because real-time stats is the key feature of their marketing advantage as I see it. Infrastructure will be setting up a secure method for receiving these logs at which point PyPI can use them. Is it done already? I am free to some degree to help with that. What is the current problem to tackle on? +1 small_rantBut: this happens all the time in open source communities, even mature ones. Someone volunteers to perform some complex task and hand-waves-away some requirement they don't personally feel is important under the too hard or I don't have time for that, I'm doing this umbrella. Someone else comes along and says wait, what happened to XXX? at which point others join in to emphasize the importance of XXX. At this point, it's more clear whether or not XXX is actually important. But during this time: XXX is broken and many people on both sides are unhappy. GOLDEN RULE: That's why even in open source, the golden rule of OPS is still important: PLEASE DO NOT BREAK SHIT. Even if you are fixing other more important functionality and don't think XXX is important. Or if XXX and the thing you want to do cannot co-exist, then make sure you get extensive buy-in from a large percentage of folks before you consider removing XXX. If for no other reason, then you will most certainly draw unwanted attention to yourself (which is especially frustrating in the context of trying to do good things). /small_rant Anyway, I've seen this so many times I don't even get angry anymore. Because I know everyone involved has nothing but the best intentions. In this case, I'd like to see the download count functionality restored. (I spent a full year building a website whose almost-sole-functionality relies on download counts existing and working properly.) So, please call me when they are back.:-) And if I can help in anyway to make that happen, please let me know. Alex ___ Distutils-SIG maillist - Distutils-SIG at python.org http://mail.python.org/mailman/listinfo/distutils-sig --- Alex Clark · http://about.me/alex.clark ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PyPI Download Counts
On Sun, Jun 09, 2013 at 01:57 +0300, anatoly techtonik wrote: On Thu, May 30, 2013 at 6:56 PM, Donald Stufft don...@stufft.io wrote: On May 30, 2013, at 8:05 AM, Jim Fulton j...@zope.com wrote: On Mon, May 27, 2013 at 3:27 AM, holger krekel hol...@merlinux.eu wrote: Hi Donald, On Sun, May 26, 2013 at 20:08 -0400, Donald Stufft wrote: Hello! As you have have noticed the download counts on PyPI are no longer updating. Originally this was due to an issue with the script that processes these download counts. However I have now removed the download counts from the PyPI webui and their use via the API is considered deprecated. There are numerous reasons for their removal/deprecation some of which are: - Technically hard to make work with the new CDN - The CDN is being donated to the PSF, and the donated tier does not offer any form of log access What would be involved money/effort wise to get such access? I didn't see an answer to this. Any idea how much this would cost? With access to logs, we could compute download counts. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Fastly has given us access to their streaming log support. That's another deal. This is just what is expected in exchange for the Real-time CDN by Fastly phrase at the bottom of the page to make it reflect the reality. I'd say that not getting access to download stats from the start is a fail on the side of PSF or whoever involved in coordination with Fastly. I also was surprised when download counts were gone but download stats aren't very reliable indicators, anyway. To begin with, one might configure a CI system to cache pypi packages, another might re-download all the time. Some popular packages are rather used from system distros, others downloaded from pypi. And there are many more issues. Seems like there are not overwhelmingly many people unhappy about its removal. Doesn't mean they shouldn't be reinstanted, just saying. There are many CDN providers out there and I suspect so far only Fastly was contacted. The primary responsibility of that coordinator is correctly sending the message for CDN provider that PyPI is a public exhibition of their service quality, and not a tax exemption for charity. I'd say Fastly should be interested to help with making us download stats exposed in a convenient API friendly way, because real-time stats is the key feature of their marketing advantage as I see it. FYI Fastly has been responding swiftly and responsibly so far, as far as i could follow it. And Donald has been helping people on various fronts (not only Fastly related) and been the main driver of the CDN move, thankfully. Things are starting to work more smoothly now and i guess some bumps in the road were unavoidable because they only show up in real life. cheers, holger Infrastructure will be setting up a secure method for receiving these logs at which point PyPI can use them. Is it done already? I am free to some degree to help with that. What is the current problem to tackle on? ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Setuptools 0.7.2 and Distribute 0.7 (compatibility wrapper) on PyPI
On behalf of the PYPA, I'm excited to announce that Setuptools 0.7 is now official and complete. Released to PyPI, Setuptools 0.7.2 is now available for all to see by default (https://pypi.python.org/pypi/setuptools/). Users of Setuptools 0.6 may upgrade by simply running `easy_install -U setuptools`. Additionally, I released Distribute 0.7 to PyPI. This means that users who have Distribute 0.6.x can upgrade to setuptools 0.7 by simply invoking `easy_install -U distribute` (or `easy_install distribute=0.7`). Windows users should use `easy_install-script -U distribute` (to avoid file in use errors on easy_install.exe). The documentation for Setuptools 0.7.2 has been uploaded to https://pythonhosted.org/setuptools and includes the notes about the merge in addition to the official documentation. Please report any issues at the project page (https://bitbucket.org/pypa/setuptools). smime.p7s Description: S/MIME cryptographic signature ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools 0.7.2 and Distribute 0.7 (compatibility wrapper) on PyPI
Yay, great news! /me adds updating the packaging essay (both copies) to his TODO list :) Cheers, Nick. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools 0.7.2 and Distribute 0.7 (compatibility wrapper) on PyPI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/09/2013 12:22 PM, Jason R. Coombs wrote: On behalf of the PYPA, I'm excited to announce that Setuptools 0.7 is now official and complete. Released to PyPI, Setuptools 0.7.2 is now available for all to see by default (https://pypi.python.org/pypi/setuptools/). Users of Setuptools 0.6 may upgrade by simply running `easy_install -U setuptools`. Additionally, I released Distribute 0.7 to PyPI. This means that users who have Distribute 0.6.x can upgrade to setuptools 0.7 by simply invoking `easy_install -U distribute` (or `easy_install distribute=0.7`). Windows users should use `easy_install-script -U distribute` (to avoid file in use errors on easy_install.exe). The documentation for Setuptools 0.7.2 has been uploaded to https://pythonhosted.org/setuptools and includes the notes about the merge in addition to the official documentation. Please report any issues at the project page (https://bitbucket.org/pypa/setuptools). Thanks for all the work that went into this release. I'm working to get buildout 2.0 to use the new setuptools, and need to encode a more-or-less permalink URL for 'ez_setup.py' -- do we not have a better URL for it than the Bitbucket 'raw' source? Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlG0t74ACgkQ+gerLs4ltQ6Q5wCg2hMoLBxfv6NIR/DTOUjdBNei kVUAnjZ9ua2gRpwXyeRw/i1CIBPeV9e0 =Ksc7 -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Setuptools/Distribute error with 0.7.2
Hi --
I'm hoping for some help with an error I'm suddenly getting with
distribute, setuptools.
It had been working fine, and seemingly overnight it stopped working. I
really don't think I changed anything.
This is part of a chef recipe, which also installs virtualenv.
It appears that a new version 0.7.2 is downloaded, but it fails to
install, and then the rollback fails, as well.
Not sure quite what is wrong here and how to fix it!
Liam
Using version 0.7.2 (newest of versions: 0.7.2, 0.7.2, 0.7.1, 0.7)
Downloading from URL
https://pypi.python.org/packages/source/s/setuptools/setuptools-0.7.2.tar.gz#md5=de44cd90f8a1c713d6c2bff67bbca65d
(from https://pypi.python.org/simple/setuptools/)
Running setup.py egg_info for package setuptools
running egg_info
creating pip-egg-info/setuptools.egg-info
writing requirements to pip-egg-info/setuptools.egg-info/requires.txt
writing pip-egg-info/setuptools.egg-info/PKG-INFO
writing top-level names to
pip-egg-info/setuptools.egg-info/top_level.txt
writing dependency_links to
pip-egg-info/setuptools.egg-info/dependency_links.txt
writing entry points to
pip-egg-info/setuptools.egg-info/entry_points.txt
writing requirements to pip-egg-info/setuptools.egg-info/requires.txt
writing pip-egg-info/setuptools.egg-info/PKG-INFO
writing top-level names to
pip-egg-info/setuptools.egg-info/top_level.txt
writing dependency_links to
pip-egg-info/setuptools.egg-info/dependency_links.txt
writing entry points to
pip-egg-info/setuptools.egg-info/entry_points.txt
writing manifest file 'pip-egg-info/setuptools.egg-info/SOURCES.txt'
warning: manifest_maker: standard file '-c' not found
reading manifest file 'pip-egg-info/setuptools.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file 'pip-egg-info/setuptools.egg-info/SOURCES.txt'
Source in /tmp/pip-build-root/setuptools has version 0.7.2, which
satisfies requirement setuptools=0.7 (from distribute-supervisor)
skipping extra ssl:sys_platform=='win32'
skipping extra ssl:sys_platform=='win32' and python_version=='2.4'
skipping extra certs
skipping extra ssl:python_version in '2.4, 2.5'
Installing collected packages: distribute, setuptools
Found existing installation: distribute 0.6.45
Uninstalling distribute:
Removing file or directory
/usr/local/lib/python2.7/dist-packages/distribute-0.6.45-py2.7.egg
Removing pth entries from
/usr/local/lib/python2.7/dist-packages/easy-install.pth:
Removing entry: ./distribute-0.6.45-py2.7.egg
Successfully uninstalled distribute
Running setup.py install for distribute
Running command /usr/bin/python -c import
setuptools;__file__='/tmp/pip-build-root/distribute/setup.py';exec(compile(open(__file__).read().replace('\r\n',
'\n'), __file__, 'exec')) install --record
/tmp/pip-5tzG3v-record/install-record.txt
--single-version-externally-managed
Traceback (most recent call last):
File string, line 1, in module
ImportError: No module named setuptools
Complete output from command /usr/bin/python -c import
setuptools;__file__='/tmp/pip-build-root/distribute/setup.py';exec(compile(open(__file__).read().replace('\r\n',
'\n'), __file__, 'exec')) install --record
/tmp/pip-5tzG3v-record/install-record.txt
--single-version-externally-managed:
Traceback (most recent call last):
File string, line 1, in module
ImportError: No module named setuptools
Rolling back uninstall of distribute
Replacing
/usr/local/lib/python2.7/dist-packages/distribute-0.6.45-py2.7.egg
Exception:
Traceback (most recent call last):
File
/usr/local/lib/python2.7/dist-packages/pip-1.3.1-py2.7.egg/pip/basecommand.py,
line 139, in main
status = self.run(options, args)
File
/usr/local/lib/python2.7/dist-packages/pip-1.3.1-py2.7.egg/pip/commands/install.py,
line 271, in run
requirement_set.install(install_options, global_options,
root=options.root_path)
File
/usr/local/lib/python2.7/dist-packages/pip-1.3.1-py2.7.egg/pip/req.py,
line 1189, in install
requirement.rollback_uninstall()
File
/usr/local/lib/python2.7/dist-packages/pip-1.3.1-py2.7.egg/pip/req.py,
line 500, in rollback_uninstall
self.uninstalled.rollback()
File
/usr/local/lib/python2.7/dist-packages/pip-1.3.1-py2.7.egg/pip/req.py,
line 1537, in rollback
pth.rollback()
AttributeError: 'str' object has no attribute 'rollback'
--
Liam Kirsher
PGP: http://liam.numenet.com/pgp/
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools 0.7.2 and Distribute 0.7 (compatibility wrapper) on PyPI
Is the bitbucket 'raw' source not suitable? It uses the version tag to indicate precisely which file is appropriate, which means we don't have to redundantly host that file elsewhere. Oh, I think I see - there's no link that doesn't change - you want a permalink for the latest stable release. I hadn't considered that use case, but you're right - we do want that. Perhaps the file could be added to pythonhosted.org alongside the documentation. Or maybe it belongs on bitbucket in `downloads`. I need to figure out which is more straightforward w.r.t. authentication. The distribute process was messy because it involved SSH and keys that had to be manually managed. I'm leaning toward uploading it to BitBucket downloads as part of the release script. I'll put ez_setup.py for 0.7.2 in downloads for now. You can assume that's where the permalink will be. If anyone has a better suggestion, please raise it. -Original Message- From: Distutils-SIG [mailto:distutils-sig- bounces+jaraco=jaraco@python.org] On Behalf Of Tres Seaver Sent: Sunday, 09 June, 2013 13:14 To: Distutils-Sig@Python.Org Subject: Re: [Distutils] Setuptools 0.7.2 and Distribute 0.7 (compatibility wrapper) on PyPI -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/09/2013 12:22 PM, Jason R. Coombs wrote: On behalf of the PYPA, I'm excited to announce that Setuptools 0.7 is now official and complete. Released to PyPI, Setuptools 0.7.2 is now available for all to see by default (https://pypi.python.org/pypi/setuptools/). Users of Setuptools 0.6 may upgrade by simply running `easy_install -U setuptools`. Additionally, I released Distribute 0.7 to PyPI. This means that users who have Distribute 0.6.x can upgrade to setuptools 0.7 by simply invoking `easy_install -U distribute` (or `easy_install distribute=0.7`). Windows users should use `easy_install-script -U distribute` (to avoid file in use errors on easy_install.exe). The documentation for Setuptools 0.7.2 has been uploaded to https://pythonhosted.org/setuptools and includes the notes about the merge in addition to the official documentation. Please report any issues at the project page (https://bitbucket.org/pypa/setuptools). Thanks for all the work that went into this release. I'm working to get buildout 2.0 to use the new setuptools, and need to encode a more-or-less permalink URL for 'ez_setup.py' -- do we not have a better URL for it than the Bitbucket 'raw' source? Tres. - -- == = Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlG0t74ACgkQ+gerLs4ltQ6Q5wCg2hMoLBxfv6NIR/DTOUjdBNe i kVUAnjZ9ua2gRpwXyeRw/i1CIBPeV9e0 =Ksc7 -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig smime.p7s Description: S/MIME cryptographic signature ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools/Distribute error with 0.7.2
Hi Liam,
Sorry for the trouble. The cause is rooted in the latest
updates to Setuptools and Distribute on PyPI which were launched today.
I believe what's happening here is pip is installing
Distribute 0.7, which triggers the uninstallation of Distribute, but
Distribute 0.7 (a compatibility wrapper) depends on a setuptools module to
be in place to install.
I'm unsure about the failed rollback. That looks like a
separate issue in pip.
Based on your report, I'm going to remove the Distribute-0.7
wrapper from PyPI until this issue is resolved. That is done.
In order to repair those envs, you may simply be able to
re-run the chef code over the environments and they may repair naturally. If
they don't, you may need to re-initialize the virtualenv (run virtualenv
again on that path) in order to revive distribute in that environment.
I hope the pip or virtualenv maintainers can comment as
well.
Regards,
Jason
From: Distutils-SIG
[mailto:distutils-sig-bounces+jaraco=jaraco@python.org] On Behalf Of
Liam Kirsher
Sent: Sunday, 09 June, 2013 13:24
To: distutils-sig@python.org
Subject: [Distutils] Setuptools/Distribute error with 0.7.2
Hi --
I'm hoping for some help with an error I'm suddenly getting with distribute,
setuptools.
It had been working fine, and seemingly overnight it stopped working. I
really don't think I changed anything.
This is part of a chef recipe, which also installs virtualenv.
It appears that a new version 0.7.2 is downloaded, but it fails to install,
and then the rollback fails, as well.
Not sure quite what is wrong here and how to fix it!
Liam
Using version 0.7.2 (newest of versions: 0.7.2, 0.7.2, 0.7.1, 0.7)
Downloading from URL
https://pypi.python.org/packages/source/s/setuptools/setuptools-0.7.2.tar.gz
#md5=de44cd90f8a1c713d6c2bff67bbca65d (from
https://pypi.python.org/simple/setuptools/)
Running setup.py egg_info for package setuptools
running egg_info
creating pip-egg-info/setuptools.egg-info
writing requirements to pip-egg-info/setuptools.egg-info/requires.txt
writing pip-egg-info/setuptools.egg-info/PKG-INFO
writing top-level names to
pip-egg-info/setuptools.egg-info/top_level.txt
writing dependency_links to
pip-egg-info/setuptools.egg-info/dependency_links.txt
writing entry points to
pip-egg-info/setuptools.egg-info/entry_points.txt
writing requirements to pip-egg-info/setuptools.egg-info/requires.txt
writing pip-egg-info/setuptools.egg-info/PKG-INFO
writing top-level names to
pip-egg-info/setuptools.egg-info/top_level.txt
writing dependency_links to
pip-egg-info/setuptools.egg-info/dependency_links.txt
writing entry points to
pip-egg-info/setuptools.egg-info/entry_points.txt
writing manifest file 'pip-egg-info/setuptools.egg-info/SOURCES.txt'
warning: manifest_maker: standard file '-c' not found
reading manifest file 'pip-egg-info/setuptools.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file 'pip-egg-info/setuptools.egg-info/SOURCES.txt'
Source in /tmp/pip-build-root/setuptools has version 0.7.2, which
satisfies requirement setuptools=0.7 (from distribute-supervisor)
skipping extra ssl:sys_platform=='win32'
skipping extra ssl:sys_platform=='win32' and python_version=='2.4'
skipping extra certs
skipping extra ssl:python_version in '2.4, 2.5'
Installing collected packages: distribute, setuptools
Found existing installation: distribute 0.6.45
Uninstalling distribute:
Removing file or directory
/usr/local/lib/python2.7/dist-packages/distribute-0.6.45-py2.7.egg
Removing pth entries from
/usr/local/lib/python2.7/dist-packages/easy-install.pth:
Removing entry: ./distribute-0.6.45-py2.7.egg
Successfully uninstalled distribute
Running setup.py install for distribute
Running command /usr/bin/python -c import
setuptools;__file__='/tmp/pip-build-root/distribute/setup.py';exec(compile(o
pen(__file__).read().replace('\r\n', '\n'), __file__, 'exec')) install
--record /tmp/pip-5tzG3v-record/install-record.txt
--single-version-externally-managed
Traceback (most recent call last):
File string, line 1, in module
ImportError: No module named setuptools
Complete output from command /usr/bin/python -c import
setuptools;__file__='/tmp/pip-build-root/distribute/setup.py';exec(compile(o
pen(__file__).read().replace('\r\n', '\n'), __file__, 'exec')) install
--record /tmp/pip-5tzG3v-record/install-record.txt
--single-version-externally-managed:
Traceback (most recent call last):
File string, line 1, in module
ImportError: No module named setuptools
Rolling back uninstall of distribute
Replacing
/usr/local/lib/python2.7/dist-packages/distribute-0.6.45-py2.7.egg
Exception:
Traceback (most recent call last):
File
Re: [Distutils] Setuptools/Distribute error with 0.7.2
On Jun 9, 2013, at 2:07 PM, Jason R. Coombs jar...@jaraco.com wrote: I believe what’s happening here is pip is installing Distribute 0.7, which triggers the uninstallation of Distribute, but Distribute 0.7 (a compatibility wrapper) depends on a setuptools module to be in place to install. If I recall pip hasn't handled the upgrade of distribute very well for awhile now but I can't see to find an existing ticket for it. There is a new one an hour ago but I assume it stems from this issue. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools/Distribute error with 0.7.2
(I was also getting this until I used easy_install to upgrade)
What is supposed to happen with stuff that used to do `use_setuptools()` in
their setup.py now?
I upgraded to setuptools 0.7.2, but now if I try to install a thing that
has that in the setup.py, it seems to want to try and install distribute,
and I get:
Downloading/unpacking pudb (from -r
/Users/Julian/.local/share/virtualenvs/requirements-every-virtualenv.txt
(line 2))
Using download cache from /Users/Julian/Library/Caches/pip/https%3A%2F%
2Fpypi.python.org%2Fpackages%2Fsource%2Fp%2Fpudb%2Fpudb-2013.2.tar.gz
Running setup.py egg_info for package pudb
Downloading
http://pypi.python.org/packages/source/d/distribute/distribute-0.6.35.tar.gz
Extracting in /var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/tmp8NepZ3
Now working in
/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/tmp8NepZ3/distribute-0.6.35
Building a Distribute egg in
/Users/Julian/.local/share/virtualenvs/great/build/pudb
Traceback (most recent call last):
File setup.py, line 45, in module
exec(init_file.read(), d)
File string, line 8, in module
File
/private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/tmp8NepZ3/distribute-0.6.35/setuptools/__init__.py,
line 2, in module
from setuptools.extension import Extension, Library
File
/private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/tmp8NepZ3/distribute-0.6.35/setuptools/extension.py,
line 5, in module
from setuptools.dist import _get_unpatched
File
/private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/tmp8NepZ3/distribute-0.6.35/setuptools/dist.py,
line 6, in module
from setuptools.command.install import install
File
/private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/tmp8NepZ3/distribute-0.6.35/setuptools/command/__init__.py,
line 8, in module
from setuptools.command import install_scripts
File
/private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/tmp8NepZ3/distribute-0.6.35/setuptools/command/install_scripts.py,
line 3, in module
from pkg_resources import Distribution, PathMetadata,
ensure_directory
File
/private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/tmp8NepZ3/distribute-0.6.35/pkg_resources.py,
line 2825, in module
add_activation_listener(lambda dist: dist.activate())
File
/private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/tmp8NepZ3/distribute-0.6.35/pkg_resources.py,
line 710, in subscribe
callback(dist)
File
/private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/tmp8NepZ3/distribute-0.6.35/pkg_resources.py,
line 2825, in lambda
add_activation_listener(lambda dist: dist.activate())
File
/private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/tmp8NepZ3/distribute-0.6.35/pkg_resources.py,
line 2257, in activate
self.insert_on(path)
File
/private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/tmp8NepZ3/distribute-0.6.35/pkg_resources.py,
line 2358, in insert_on
with distribute. Found one at %s % str(self.location))
ValueError: A 0.7-series setuptools cannot be installed with
distribute. Found one at
/Users/Julian/.local/share/virtualenvs/great/lib/python2.7/site-packages/setuptools-0.7.2-py2.7.egg
/Users/Julian/.local/share/virtualenvs/great/build/pudb/distribute-0.6.35-py2.7.egg
Traceback (most recent call last):
File string, line 16, in module
File
/Users/Julian/.local/share/virtualenvs/great/build/pudb/setup.py, line 5,
in module
use_setuptools()
File distribute_setup.py, line 152, in use_setuptools
return _do_download(version, download_base, to_dir, download_delay)
File distribute_setup.py, line 132, in _do_download
_build_egg(egg, tarball, to_dir)
File distribute_setup.py, line 123, in _build_egg
raise IOError('Could not build the egg.')
IOError: Could not build the egg.
Complete output from command python setup.py egg_info:
Downloading
http://pypi.python.org/packages/source/d/distribute/distribute-0.6.35.tar.gz
Extracting in /var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/tmp8NepZ3
Now working in
/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/tmp8NepZ3/distribute-0.6.35
Building a Distribute egg in
/Users/Julian/.local/share/virtualenvs/great/build/pudb
Traceback (most recent call last):
File setup.py, line 45, in module
exec(init_file.read(), d)
File string, line 8, in module
File
/private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/tmp8NepZ3/distribute-0.6.35/setuptools/__init__.py,
line 2, in module
from setuptools.extension import Extension, Library
File
/private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/tmp8NepZ3/distribute-0.6.35/setuptools/extension.py,
line 5, in module
from setuptools.dist import _get_unpatched
File
/private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/tmp8NepZ3/distribute-0.6.35/setuptools/dist.py,
line 6, in module
from
Re: [Distutils] Setuptools/Distribute error with 0.7.2
Thanks! That's a relief.
I re-ran it and it worked.
On 06/09/2013 11:07 AM, Jason R. Coombs wrote:
Hi Liam,
Sorry for the trouble. The cause is rooted in the
latest updates to Setuptools and Distribute on PyPI which were
launched today.
I believe what's happening here is pip is installing
Distribute 0.7, which triggers the uninstallation of Distribute, but
Distribute 0.7 (a compatibility wrapper) depends on a setuptools
module to be in place to install.
I'm unsure about the failed rollback. That looks like
a separate issue in pip.
Based on your report, I'm going to remove the
Distribute-0.7 wrapper from PyPI until this issue is resolved. That is
done.
In order to repair those envs, you may simply be able
to re-run the chef code over the environments and they may repair
naturally. If they don't, you may need to re-initialize the virtualenv
(run virtualenv again on that path) in order to revive distribute in
that environment.
I hope the pip or virtualenv maintainers can comment
as well.
Regards,
Jason
*From:*Distutils-SIG
[mailto:distutils-sig-bounces+jaraco=jaraco@python.org] *On Behalf
Of *Liam Kirsher
*Sent:* Sunday, 09 June, 2013 13:24
*To:* distutils-sig@python.org
*Subject:* [Distutils] Setuptools/Distribute error with 0.7.2
Hi --
I'm hoping for some help with an error I'm suddenly getting with
distribute, setuptools.
It had been working fine, and seemingly overnight it stopped working.
I really don't think I changed anything.
This is part of a chef recipe, which also installs virtualenv.
It appears that a new version 0.7.2 is downloaded, but it fails to
install, and then the rollback fails, as well.
Not sure quite what is wrong here and how to fix it!
Liam
Using version 0.7.2 (newest of versions: 0.7.2, 0.7.2, 0.7.1, 0.7)
Downloading from URL
https://pypi.python.org/packages/source/s/setuptools/setuptools-0.7.2.tar.gz#md5=de44cd90f8a1c713d6c2bff67bbca65d
(from https://pypi.python.org/simple/setuptools/)
Running setup.py egg_info for package setuptools
running egg_info
creating pip-egg-info/setuptools.egg-info
writing requirements to
pip-egg-info/setuptools.egg-info/requires.txt
writing pip-egg-info/setuptools.egg-info/PKG-INFO
writing top-level names to
pip-egg-info/setuptools.egg-info/top_level.txt
writing dependency_links to
pip-egg-info/setuptools.egg-info/dependency_links.txt
writing entry points to
pip-egg-info/setuptools.egg-info/entry_points.txt
writing requirements to
pip-egg-info/setuptools.egg-info/requires.txt
writing pip-egg-info/setuptools.egg-info/PKG-INFO
writing top-level names to
pip-egg-info/setuptools.egg-info/top_level.txt
writing dependency_links to
pip-egg-info/setuptools.egg-info/dependency_links.txt
writing entry points to
pip-egg-info/setuptools.egg-info/entry_points.txt
writing manifest file
'pip-egg-info/setuptools.egg-info/SOURCES.txt'
warning: manifest_maker: standard file '-c' not found
reading manifest file
'pip-egg-info/setuptools.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file
'pip-egg-info/setuptools.egg-info/SOURCES.txt'
Source in /tmp/pip-build-root/setuptools has version 0.7.2,
which satisfies requirement setuptools=0.7 (from
distribute-supervisor)
skipping extra ssl:sys_platform=='win32'
skipping extra ssl:sys_platform=='win32' and python_version=='2.4'
skipping extra certs
skipping extra ssl:python_version in '2.4, 2.5'
Installing collected packages: distribute, setuptools
Found existing installation: distribute 0.6.45
Uninstalling distribute:
Removing file or directory
/usr/local/lib/python2.7/dist-packages/distribute-0.6.45-py2.7.egg
Removing pth entries from
/usr/local/lib/python2.7/dist-packages/easy-install.pth:
Removing entry: ./distribute-0.6.45-py2.7.egg
Successfully uninstalled distribute
Running setup.py install for distribute
Running command /usr/bin/python -c import
setuptools;__file__='/tmp/pip-build-root/distribute/setup.py';exec(compile(open(__file__).read().replace('\r\n',
'\n'), __file__, 'exec')) install --record
/tmp/pip-5tzG3v-record/install-record.txt
--single-version-externally-managed
Traceback (most recent call last):
File string, line 1, in module
ImportError: No module named setuptools
Complete output from command /usr/bin/python -c import
setuptools;__file__='/tmp/pip-build-root/distribute/setup.py';exec(compile(open(__file__).read().replace('\r\n',
'\n'),
Re: [Distutils] PyPI Download Counts
On Jun 9, 2013, at 9:20 AM, holger krekel hol...@merlinux.eu wrote: There are many CDN providers out there and I suspect so far only Fastly was contacted. The primary responsibility of that coordinator is correctly sending the message for CDN provider that PyPI is a public exhibition of their service quality, and not a tax exemption for charity. I'd say Fastly should be interested to help with making us download stats exposed in a convenient API friendly way, because real-time stats is the key feature of their marketing advantage as I see it. FYI Fastly has been responding swiftly and responsibly so far, as far as i could follow it. And Donald has been helping people on various fronts (not only Fastly related) and been the main driver of the CDN move, thankfully. Things are starting to work more smoothly now and i guess some bumps in the road were unavoidable because they only show up in real life. Fastly has been a dream to work with. They've been fast at fixing and diagnosing issues, have helped tune the config to get a higher hit rate, and when they heard that people were upset that download counts had to be turned off they offered the logging support to be turned on for our account. The infrastructure is setup to receive the logs (and intact was receiving logs for a day or so) but upgrades to the VM that runs PyPI needs to occur before we can continue receiving them. The disk drive that PyPI has is to small to handle the volume of request data that is coming in from Fastly and it quickly filled up in under 24 hours. Upgrading that space requires powering off the VM so we (The Infra team) are working on doing that, ideally without downtime on PyPI. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools 0.7.2 and Distribute 0.7 (compatibility wrapper) on PyPI
I'm dancing a small victory-dance in my chair. On Sun, Jun 9, 2013 at 6:22 PM, Jason R. Coombs jar...@jaraco.com wrote: On behalf of the PYPA, I’m excited to announce that Setuptools 0.7 is now official and complete. Released to PyPI, Setuptools 0.7.2 is now available for all to see by default (https://pypi.python.org/pypi/setuptools/). Users of Setuptools 0.6 may upgrade by simply running `easy_install -U setuptools`. Additionally, I released Distribute 0.7 to PyPI. This means that users who have Distribute 0.6.x can upgrade to setuptools 0.7 by simply invoking `easy_install -U distribute` (or `easy_install distribute=0.7”`). Windows users should use `easy_install-script -U distribute` (to avoid “file in use” errors on easy_install.exe). The documentation for Setuptools 0.7.2 has been uploaded to https://pythonhosted.org/setuptools and includes the notes about the merge in addition to the official documentation. Please report any issues at the project page (https://bitbucket.org/pypa/setuptools). ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PyPI Download Counts
On Jun 9, 2013, at 8:53 AM, Alex Clark acl...@aclark.net wrote: small_rantBut: this happens all the time in open source communities, even mature ones. Someone volunteers to perform some complex task and hand-waves-away some requirement they don't personally feel is important under the too hard or I don't have time for that, I'm doing this umbrella. Someone else comes along and says wait, what happened to XXX? at which point others join in to emphasize the importance of XXX. At this point, it's more clear whether or not XXX is actually important. But during this time: XXX is broken and many people on both sides are unhappy. GOLDEN RULE: That's why even in open source, the golden rule of OPS is still important: PLEASE DO NOT BREAK SHIT. Even if you are fixing other more important functionality and don't think XXX is important. Or if XXX and the thing you want to do cannot co-exist, then make sure you get extensive buy-in from a large percentage of folks before you consider removing XXX. If for no other reason, then you will most certainly draw unwanted attention to yourself (which is especially frustrating in the context of trying to do good things). /small_rant Anyway, I've seen this so many times I don't even get angry anymore. Because I know everyone involved has nothing but the best intentions. In this case, I'd like to see the download count functionality restored. (I spent a full year building a website whose almost-sole-functionality relies on download counts existing and working properly.) So, please call me when they are back.:-) And if I can help in anyway to make that happen, please let me know. PyPI's central purpose is to act as a repository and index of packages. Download counts are an auxiliary feature. Prior to the CDN there were large swathes of people, primarily in non US locations, who simply could not use PyPI because of bad routes between them and PyPI. Some folks were getting download speeds more reminiscent of dialup instead of Broadband. Moving to a CDN made PyPI reasonably function again for those people. So yes. I broke Download counts because they were not more important than people being able to actually use PyPI to install from. And, thanks to Fastly generously giving us a access to streaming logs, will be bringing them back once the issues are sorted out. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools/Distribute error with 0.7.2
If I recall pip hasn't handled the upgrade of distribute very well for awhile now but I can't see to find an existing ticket for it. the older issue is that pip can't upgrade distribute in python 3 (related to distribute requiring 2to3) https://github.com/pypa/pip/issues/650 btw, pip-1.4 (unreleased) has new logic to skip even trying, because the problem prevents upgrades and wheel building for projects like pyramid (which formally depend on setuptools) Marcus ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools/Distribute error with 0.7.2
Hi Julian,
I believe for those packages that call `use_setuptools()`
from `distribute_setup.py`, the only option to support them is to install
Distribute 0.7 (the stub package), which I believe will satisfy the
use_setuptools() call so it doesn't attempt to install Distribute 0.6.
As mentioned in another post, I've temporarily pulled
Distribute 0.7 from PyPI until we can determine a way to avoid the pip
upgrade issue. In the meantime, if you install Distribute 0.7 from
https://bitbucket.org/pypa/setuptools/downloads, does that solve your issue?
Regards,
Jason
From: Distutils-SIG
[mailto:distutils-sig-bounces+jaraco=jaraco@python.org] On Behalf Of
Julian Berman
Sent: Sunday, 09 June, 2013 14:21
To: distutils-sig@python.org
Subject: Re: [Distutils] Setuptools/Distribute error with 0.7.2
(I was also getting this until I used easy_install to upgrade)
What is supposed to happen with stuff that used to do `use_setuptools()` in
their setup.py now?
I upgraded to setuptools 0.7.2, but now if I try to install a thing that has
that in the setup.py, it seems to want to try and install distribute, and I
get:
Downloading/unpacking pudb (from -r
/Users/Julian/.local/share/virtualenvs/requirements-every-virtualenv.txt
(line 2))
Using download cache from
/Users/Julian/Library/Caches/pip/https%3A%2F%2Fpypi.python.org
http://2Fpypi.python.org
%2Fpackages%2Fsource%2Fp%2Fpudb%2Fpudb-2013.2.tar.gz
Running setup.py egg_info for package pudb
Downloading
http://pypi.python.org/packages/source/d/distribute/distribute-0.6.35.tar.gz
Extracting in /var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/tmp8NepZ3
Now working in
/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/tmp8NepZ3/distribute-0.6.35
Building a Distribute egg in
/Users/Julian/.local/share/virtualenvs/great/build/pudb
Traceback (most recent call last):
File setup.py, line 45, in module
exec(init_file.read(), d)
File string, line 8, in module
File
/private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/tmp8NepZ3/distribu
te-0.6.35/setuptools/__init__.py, line 2, in module
from setuptools.extension import Extension, Library
File
/private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/tmp8NepZ3/distribu
te-0.6.35/setuptools/extension.py, line 5, in module
from setuptools.dist import _get_unpatched
File
/private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/tmp8NepZ3/distribu
te-0.6.35/setuptools/dist.py, line 6, in module
from setuptools.command.install import install
File
/private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/tmp8NepZ3/distribu
te-0.6.35/setuptools/command/__init__.py, line 8, in module
from setuptools.command import install_scripts
File
/private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/tmp8NepZ3/distribu
te-0.6.35/setuptools/command/install_scripts.py, line 3, in module
from pkg_resources import Distribution, PathMetadata,
ensure_directory
File
/private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/tmp8NepZ3/distribu
te-0.6.35/pkg_resources.py, line 2825, in module
add_activation_listener(lambda dist: dist.activate())
File
/private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/tmp8NepZ3/distribu
te-0.6.35/pkg_resources.py, line 710, in subscribe
callback(dist)
File
/private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/tmp8NepZ3/distribu
te-0.6.35/pkg_resources.py, line 2825, in lambda
add_activation_listener(lambda dist: dist.activate())
File
/private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/tmp8NepZ3/distribu
te-0.6.35/pkg_resources.py, line 2257, in activate
self.insert_on(path)
File
/private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/tmp8NepZ3/distribu
te-0.6.35/pkg_resources.py, line 2358, in insert_on
with distribute. Found one at %s % str(self.location))
ValueError: A 0.7-series setuptools cannot be installed with distribute.
Found one at
/Users/Julian/.local/share/virtualenvs/great/lib/python2.7/site-packages/set
uptools-0.7.2-py2.7.egg
/Users/Julian/.local/share/virtualenvs/great/build/pudb/distribute-0.6.35-py
2.7.egg
Traceback (most recent call last):
File string, line 16, in module
File
/Users/Julian/.local/share/virtualenvs/great/build/pudb/setup.py, line 5,
in module
use_setuptools()
File distribute_setup.py, line 152, in use_setuptools
return _do_download(version, download_base, to_dir, download_delay)
File distribute_setup.py, line 132, in _do_download
_build_egg(egg, tarball, to_dir)
File distribute_setup.py, line 123, in _build_egg
raise IOError('Could not build the egg.')
IOError: Could not build the egg.
Complete output from command python setup.py egg_info:
Downloading
Re: [Distutils] b.pypi.python.org
On Jun 7, 2013, at 2:34 PM, Noah Kantrowitz n...@coderanger.net wrote: On Jun 7, 2013, at 2:27 PM, Donald Stufft don...@stufft.io wrote: On Jun 7, 2013, at 5:26 PM, ken cochrane kencochr...@gmail.com wrote: b.pypi.python.org is an official mirror that runs on Google App engine, and it uses a special mirror package built just for GAE. Code for it is found here. https://bitbucket.org/loewis/pypi-appengine b.pypi.python.org has been broken for over 104 days according to http://www.pypi-mirrors.org, and this is because of an issue when we switched pypi over to serving over SSL. I have submitted a pull request to fix this. https://bitbucket.org/loewis/pypi-appengine/pull-request/2/change-pypi-mirror-connection-to-https/diff#comment-262919 but it hasn't been accepted. I am one of the maintainers of b.pypi.python.org, so I can see the logs and push out a new version. I haven't needed to push a version out before, and I'm a little hesitant incase I do it wrong and break something. I also don't want to push code to GAE from my fork, until my PR gets accepted or else someone else in the future might deploy the original one again and remove my fix. Two things: 1. Now that we have the pypi CDN up, do we still need this mirror? Honestly probably not. Mirrors are less important from a availability/speed side of things now and will likely move to being more useful for companies and such to use. OK, what would be the procedure for removing a mirror? Anyone know who is in charge of this mirror? I think Guido had it setup when he worked at Google, and google is paying for the costs of the mirror, but now that he doesn't work for Google, not sure who might be the contact person on that side. I've asked Guido who are admins on the account it to get it turned off. If he doesn't know I can try to find out internally. Brett, Here is the owner list that I can see on GAE - guido - kencochrane (me) - kumar.mcmillan - martin.v.loewis - r1chardj0n3s So Guido didn't even know he was an owner. =) In terms of shutting down the app, you will want to do two things. First is empty out the cron.yaml file; it should have nothing more than cron:. After that you probably want to return 404 for everything; see http://stackoverflow.com/a/189935/236574 on how to do that for all URLs. If you want, Ken, I can clone https://bitbucket.org/kencochrane/pypi-appengine and send you a pull request to do all of this since I recently did something similar for py3ksupport.appspot.com when I shut it down. Brett, If our goal is to shut it down, then yes please, if you can send a pull request that would be great.. We should also probably remove it from the pypi mirror pool before we do this so it no longer gets traffic sent it's way. If we can get it up to date again, I think it is fine, but an out of date mirror is not useful to anyone, and it could cause problems in the long run. 2. If yes to 1. if someone can take a minute to review my PR, and leave comments, or if you have the power, accept my pull request and push out a new version so we can get the mirror up to date. I don't have such permission sadly. Thank you anyway. Paging Noah to kill the DNS Unless there's any objections to removing it? If no one complains in the next 24-ish hours I'll just point it back at pypi.python.org like we did with d.pypi. This is now complete. In another 24 hours there should be no traffic to the GAE app and it can just be archived or deleted. --Noah signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PyPI Download Counts
Donald Stufft donald at stufft.io writes: So yes. I broke Download counts because they were not more important than people being able to actually use PyPI to install from. FWIW: You missed the moral of the story: when you make a decision like this, someone will *always* disagree with you (even over the most trivial things). And even if they don't, they may disagree with your approach (e.g. why not sort problems with download counts before enabling the CDN) So the only way to make everyone happy is to consider everyone who will be affected by your actions, before you take action. (I'm not that concerned with this particular incident, just fascinated by open source community relations in general.) Alex - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Distutils-SIG maillist - Distutils-SIG at python.org http://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PyPI Download Counts
On Jun 9, 2013, at 1:04 PM, Alex Clark acl...@aclark.net wrote: Donald Stufft donald at stufft.io writes: So yes. I broke Download counts because they were not more important than people being able to actually use PyPI to install from. FWIW: You missed the moral of the story: when you make a decision like this, someone will *always* disagree with you (even over the most trivial things). And even if they don't, they may disagree with your approach (e.g. why not sort problems with download counts before enabling the CDN) So the only way to make everyone happy is to consider everyone who will be affected by your actions, before you take action. There is another way, make awesome and wait for history to determine who was happy :) --Noah signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PyPI Download Counts
On Sun, Jun 9, 2013 at 8:41 PM, Donald Stufft don...@stufft.io wrote: So yes. I broke Download counts because they were not more important than people being able to actually use PyPI to install from. I approve of this message. //Lennart ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools/Distribute error with 0.7.2
Hey Jason. I was getting it before you removed it I think (and yeah, still get it now if I `pip install https://bitbucket.org/pypa/setuptools/downloads/distribute-0.7.zip`). An example of such a package is pudb, if you'd like to try and reproduce (or I can open an issue on the tracker, just wasn't sure I wasn't missing something), but even if I install with easy_install I still seem to get the same output: ⊙ easy_install pudb Julian@air Searching for pudb Reading https://pypi.python.org/simple/pudb/ Best match: pudb 2013.2 Downloading https://pypi.python.org/packages/source/p/pudb/pudb-2013.2.tar.gz#md5=16411aaffc6f7ae63aba3830ba4ebee5 Processing pudb-2013.2.tar.gz Writing /var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/easy_install-URSqF1/pudb-2013.2/setup.cfg Running pudb-2013.2/setup.py -q bdist_egg --dist-dir /var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/easy_install-URSqF1/pudb-2013.2/egg-dist-tmp-6RBU6H Downloading http://pypi.python.org/packages/source/d/distribute/distribute-0.6.35.tar.gz Extracting in /var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/easy_install-URSqF1/pudb-2013.2/temp/tmpBW8hGl Now working in /var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/easy_install-URSqF1/pudb-2013.2/temp/tmpBW8hGl/distribute-0.6.35 Building a Distribute egg in /private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/easy_install-URSqF1/pudb-2013.2 Traceback (most recent call last): File setup.py, line 45, in module exec(init_file.read(), d) File string, line 8, in module File /private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/easy_install-URSqF1/pudb-2013.2/temp/tmpBW8hGl/distribute-0.6.35/setuptools/__init__.py, line 2, in module from setuptools.extension import Extension, Library File /private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/easy_install-URSqF1/pudb-2013.2/temp/tmpBW8hGl/distribute-0.6.35/setuptools/extension.py, line 5, in module from setuptools.dist import _get_unpatched File /private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/easy_install-URSqF1/pudb-2013.2/temp/tmpBW8hGl/distribute-0.6.35/setuptools/dist.py, line 6, in module from setuptools.command.install import install File /private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/easy_install-URSqF1/pudb-2013.2/temp/tmpBW8hGl/distribute-0.6.35/setuptools/command/__init__.py, line 8, in module from setuptools.command import install_scripts File /private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/easy_install-URSqF1/pudb-2013.2/temp/tmpBW8hGl/distribute-0.6.35/setuptools/command/install_scripts.py, line 3, in module from pkg_resources import Distribution, PathMetadata, ensure_directory File /private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/easy_install-URSqF1/pudb-2013.2/temp/tmpBW8hGl/distribute-0.6.35/pkg_resources.py, line 2825, in module add_activation_listener(lambda dist: dist.activate()) File /private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/easy_install-URSqF1/pudb-2013.2/temp/tmpBW8hGl/distribute-0.6.35/pkg_resources.py, line 710, in subscribe callback(dist) File /private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/easy_install-URSqF1/pudb-2013.2/temp/tmpBW8hGl/distribute-0.6.35/pkg_resources.py, line 2825, in lambda add_activation_listener(lambda dist: dist.activate()) File /private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/easy_install-URSqF1/pudb-2013.2/temp/tmpBW8hGl/distribute-0.6.35/pkg_resources.py, line 2257, in activate self.insert_on(path) File /private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/easy_install-URSqF1/pudb-2013.2/temp/tmpBW8hGl/distribute-0.6.35/pkg_resources.py, line 2358, in insert_on with distribute. Found one at %s % str(self.location)) ValueError: A 0.7-series setuptools cannot be installed with distribute. Found one at /usr/local/lib/python2.7/site-packages/setuptools-0.7.2-py2.7.egg /private/var/folders/zc/bzrwlgxd51594q6lt1yrx5v0gn/T/easy_install-URSqF1/pudb-2013.2/distribute-0.6.35-py2.7.egg error: None ~ ⊙ pip freeze | grep distribute Julian@air distribute==0.7 On Sun, Jun 9, 2013 at 2:29 PM, Jason R. Coombs jar...@jaraco.com wrote: Hi Julian, I believe for those packages that call `use_setuptools()` from `distribute_setup.py`, the only option to support them is to install Distribute 0.7 (the stub package), which I believe will satisfy the use_setuptools() call so it doesn’t attempt to install Distribute 0.6. ** ** As mentioned in another post, I’ve temporarily pulled Distribute 0.7 from PyPI until we can determine a way to avoid the pip upgrade issue. In the meantime, if you install Distribute 0.7 from https://bitbucket.org/pypa/setuptools/downloads, does that solve your issue? ** ** Regards, Jason ** ** *From:* Distutils-SIG [mailto:distutils-sig-bounces+jaraco= jaraco@python.org] *On Behalf Of *Julian Berman *Sent:* Sunday, 09 June, 2013 14:21 *To:*
Re: [Distutils] b.pypi.python.org
On Jun 9, 2013, at 3:46 PM, Noah Kantrowitz n...@coderanger.net wrote: On Jun 7, 2013, at 2:34 PM, Noah Kantrowitz n...@coderanger.net wrote: On Jun 7, 2013, at 2:27 PM, Donald Stufft don...@stufft.io wrote: On Jun 7, 2013, at 5:26 PM, ken cochrane kencochr...@gmail.com wrote: b.pypi.python.org is an official mirror that runs on Google App engine, and it uses a special mirror package built just for GAE. Code for it is found here. https://bitbucket.org/loewis/pypi-appengine b.pypi.python.org has been broken for over 104 days according to http://www.pypi-mirrors.org, and this is because of an issue when we switched pypi over to serving over SSL. I have submitted a pull request to fix this. https://bitbucket.org/loewis/pypi-appengine/pull-request/2/change-pypi-mirror-connection-to-https/diff#comment-262919 but it hasn't been accepted. I am one of the maintainers of b.pypi.python.org, so I can see the logs and push out a new version. I haven't needed to push a version out before, and I'm a little hesitant incase I do it wrong and break something. I also don't want to push code to GAE from my fork, until my PR gets accepted or else someone else in the future might deploy the original one again and remove my fix. Two things: 1. Now that we have the pypi CDN up, do we still need this mirror? Honestly probably not. Mirrors are less important from a availability/speed side of things now and will likely move to being more useful for companies and such to use. OK, what would be the procedure for removing a mirror? Anyone know who is in charge of this mirror? I think Guido had it setup when he worked at Google, and google is paying for the costs of the mirror, but now that he doesn't work for Google, not sure who might be the contact person on that side. I've asked Guido who are admins on the account it to get it turned off. If he doesn't know I can try to find out internally. Brett, Here is the owner list that I can see on GAE - guido - kencochrane (me) - kumar.mcmillan - martin.v.loewis - r1chardj0n3s So Guido didn't even know he was an owner. =) In terms of shutting down the app, you will want to do two things. First is empty out the cron.yaml file; it should have nothing more than cron:. After that you probably want to return 404 for everything; see http://stackoverflow.com/a/189935/236574 on how to do that for all URLs. If you want, Ken, I can clone https://bitbucket.org/kencochrane/pypi-appengine and send you a pull request to do all of this since I recently did something similar for py3ksupport.appspot.com when I shut it down. Brett, If our goal is to shut it down, then yes please, if you can send a pull request that would be great.. We should also probably remove it from the pypi mirror pool before we do this so it no longer gets traffic sent it's way. If we can get it up to date again, I think it is fine, but an out of date mirror is not useful to anyone, and it could cause problems in the long run. 2. If yes to 1. if someone can take a minute to review my PR, and leave comments, or if you have the power, accept my pull request and push out a new version so we can get the mirror up to date. I don't have such permission sadly. Thank you anyway. Paging Noah to kill the DNS Unless there's any objections to removing it? If no one complains in the next 24-ish hours I'll just point it back at pypi.python.org like we did with d.pypi. This is now complete. In another 24 hours there should be no traffic to the GAE app and it can just be archived or deleted. Thank you! ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] PEP439 and upgrading pip
maybe this was covered before, but I'm looking for clarification on how pip upgrades are to work under PEP439. I see 3 relevant bits right now: 1) attempts to import pip machinery. If it can then the pip command proceeds as normal i.e., once it has a pip installed, it doesn't automatically upgrade on subsequent imports. 2) A bootstrap is used in the place of a the full pip code so that we don't have to bundle pip and also the install tool is upgradeable outside of the regular Python upgrade timeframe and processes to be clear, what is the install tool here? pip? or the bootstrap? 3) Manual installation of the pip implementation will be supported through the manual download of the wheel file and pip3 install downloaded wheel file. This installation will not perform standard pip installation steps of saving the file to a cache directory or updating any local database of installed files. I guess this means manual upgrades as well? this special logic is to be inside pip itself? or an override of install in the bootstrap (that detects when it's a pip wheel)? Marcus ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Open source community relations: Was: Re: PyPI Download Counts
Noah Kantrowitz noah at coderanger.net writes: There is another way, make awesome and wait for history to determine who was happy :) Tee hee hee! :-) OK this is my 3rd (and likely last) attempt to steer this thread away from the specific, and contemplate the broader implications. The PyPI CDN is awesome (seriously, I appreciate all the hard work and progress from Donald, Noah, Fastly, et al, as I've said recently in another thread). And I'm prepared to be the only one interested in discussing the broader implications, at which point I'll go OT and shut up. But FWIW I bother to comment here for a reason: to learn from this incident and apply that knowledge to future incidents, and to help others do the same. Alex --Noah ___ Distutils-SIG maillist - Distutils-SIG at python.org http://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools/Distribute error with 0.7.2
It was only working in python2 before now anyway. ( https://github.com/pypa/pip/issues/650) pip is fundamentally dependent on setuptools to perform upgrades. with distribute-0.6.X upgrades, even though pip uninstalled distribute as part of the upgrade, it ran the install subprocess with the cwd equal to the build dir, so it could import setuptools from the unpacked download. but now, distribute-0.7 is just a shell, that contains no importable setuptools that pip can use. we could *make* it work I guess, by enforcing non-standard logic when dealing with distribute (i.e. get setuptools-0.7 installed first; by default, setuptools gets queued to be installed after the distribute upgrade) but like I said before, it's much more motivating to think about PEP439, than this dreary setuptools/distribute legacy headache stuff. Marcus the best fix I think is to move faster on making pip PEP439 compliant - i.e. have pip be able to at least install from wheels w/o needing setuptools, which would remove the bootstrap headache - see https://github.com/pypa/pip/issues/863 - this could likely involve pip replacing it's use of pkg_resources with distlib (https://github.com/pypa/pip/pull/909) Marcus ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Permission Denied errors on Windows 7 with buildout 1.7.1
Hi All, I'm seeing this exception when running a particular buildout on Windows: C:\Jenkins\workspace\checker-buildout\aeb5917bbin\buildout Develop: 'C:\\Jenkins\\workspace\\checker-buildout\\aeb5917b\\.' Installing py. Generated script 'C:\\Jenkins\\workspace\\checker-buildout\\aeb5917b\\bin\\checker'. Generated script 'C:\\Jenkins\\workspace\\checker-buildout\\aeb5917b\\bin\\tox'. Generated script 'C:\\Jenkins\\workspace\\checker-buildout\\aeb5917b\\bin\\tox-quickstart'. While: Installing py. An internal error occurred due to a bug in either zc.buildout or in a recipe being used: Traceback (most recent call last): File c:\users\jenkins\.buildout\eggs\zc.buildout-1.7.1-py2.7.egg\zc\buildout\buildout.py, line 1866, in main getattr(buildout, command)(args) File c:\users\jenkins\.buildout\eggs\zc.buildout-1.7.1-py2.7.egg\zc\buildout\buildout.py, line 625, in install installed_files = self[part]._call(recipe.install) File c:\users\jenkins\.buildout\eggs\zc.buildout-1.7.1-py2.7.egg\zc\buildout\buildout.py, line 1345, in _call return f() File c:\users\jenkins\.buildout\eggs\zc.recipe.egg-1.3.2-py2.7.egg\zc\recipe\egg\egg.py, line 173, in install return self._install(reqs, ws, scripts) File c:\users\jenkins\.buildout\eggs\zc.recipe.egg-1.3.2-py2.7.egg\zc\recipe\egg\egg.py, line 195, in _install relative_paths=self._relative_paths File c:\users\jenkins\.buildout\eggs\zc.buildout-1.7.1-py2.7.egg\zc\buildout\easy_install.py, line 1223, in scripts initialization, executable, arguments) File c:\users\jenkins\.buildout\eggs\zc.buildout-1.7.1-py2.7.egg\zc\buildout\easy_install.py, line 1350, in _generate_scripts module_name, attrs, arguments, block_site=block_site)) File c:\users\jenkins\.buildout\eggs\zc.buildout-1.7.1-py2.7.egg\zc\buildout\easy_install.py, line 1498, in _script return _write_script(dest, contents, 'script') File c:\users\jenkins\.buildout\eggs\zc.buildout-1.7.1-py2.7.egg\zc\buildout\easy_install.py, line 1463, in _write_script open(exe, 'wb').write(new_data) IOError: [Errno 13] Permission denied: 'C:\\Jenkins\\workspace\\checker-buildout\\aeb5917b\\bin\\buildout.exe' This happens every time, on Python 2.5, 2.6 and 2.7. I've tried blowing the workspace away, makes no difference: http://jenkins.simplistix.co.uk/job/checker-buildout/114/PYTHON=2.7,label=windows/console http://jenkins.simplistix.co.uk/job/checker-buildout/114/PYTHON=2.6,label=windows/console http://jenkins.simplistix.co.uk/job/checker-buildout/114/PYTHON=2.5,label=windows/console Any idea what's going on here and how I can fix it? cheers, Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Permission Denied errors on Windows 7 with buildout 1.7.1
On 09/06/2013 23:39, Chris Withers wrote: This happens every time, on Python 2.5, 2.6 and 2.7. I've tried blowing the workspace away, makes no difference: http://jenkins.simplistix.co.uk/job/checker-buildout/114/PYTHON=2.7,label=windows/console http://jenkins.simplistix.co.uk/job/checker-buildout/114/PYTHON=2.6,label=windows/console http://jenkins.simplistix.co.uk/job/checker-buildout/114/PYTHON=2.5,label=windows/console Forgot to say, the buildout in question is here: https://github.com/Simplistix/checker/blob/master/buildout.cfg cheers, Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools 0.7.2 and Distribute 0.7 (compatibility wrapper) on PyPI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/09/2013 01:49 PM, Jason R. Coombs wrote: Is the bitbucket 'raw' source not suitable? It uses the version tag to indicate precisely which file is appropriate, which means we don't have to redundantly host that file elsewhere. Oh, I think I see - there's no link that doesn't change - you want a permalink for the latest stable release. I hadn't considered that use case, but you're right - we do want that. Perhaps the file could be added to pythonhosted.org alongside the documentation. Or maybe it belongs on bitbucket in `downloads`. I need to figure out which is more straightforward w.r.t. authentication. The distribute process was messy because it involved SSH and keys that had to be manually managed. I'm leaning toward uploading it to BitBucket downloads as part of the release script. I'll put ez_setup.py for 0.7.2 in downloads for now. You can assume that's where the permalink will be. If anyone has a better suggestion, please raise it. I would prefer a URL on a host managed by the Python infrastructure team: either PyPI or the pythonhosted org. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlG1B2sACgkQ+gerLs4ltQ7H8gCdE/g1UBfr74s7v5tmuHLXdktx 3L0AoMxPG48F5KM8Ae+v5A1g9nU2B4To =pTON -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools 0.7.2 and Distribute 0.7 (compatibility wrapper) on PyPI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/9/2013 6:53 PM, Tres Seaver wrote: On 06/09/2013 01:49 PM, Jason R. Coombs wrote: Is the bitbucket 'raw' source not suitable? It uses the version tag to indicate precisely which file is appropriate, which means we don't have to redundantly host that file elsewhere. Oh, I think I see - there's no link that doesn't change - you want a permalink for the latest stable release. I hadn't considered that use case, but you're right - we do want that. Perhaps the file could be added to pythonhosted.org alongside the documentation. Or maybe it belongs on bitbucket in `downloads`. I need to figure out which is more straightforward w.r.t. authentication. The distribute process was messy because it involved SSH and keys that had to be manually managed. I'm leaning toward uploading it to BitBucket downloads as part of the release script. I'll put ez_setup.py for 0.7.2 in downloads for now. You can assume that's where the permalink will be. If anyone has a better suggestion, please raise it. I would prefer a URL on a host managed by the Python infrastructure team: either PyPI or the pythonhosted org. And benefiting from the PyPI CDN would be great. - -- Eric. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (Cygwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRtQ1oAAoJENxauZFcKtNxHVsH/1AXswEmeQAjH/GuRqOmNoQH uDIE6D/y3wrld0fyzejpKqponaaiiChvwqfFCL+TU47qsScOl9eyBAoylgeCvVoR cAmeDlyrn52RILKE9F5p9BhAeFTtWdi+87LIvv3BWu0y/HdrWiYoCMA94xyolSF9 rLPb4hJuVlsau3+jcxi5iNtlTMRsyL1wYrygAmnp7tcJ3LiQ23SQI9kxhdGXvunY vQvzptMEZOLktyX+5A4IPiFXzsuPkLY5RYD7F+7B/Sn6oH8TSNLEbmagP4U3C/bX 7TAMT4MDTs2tzcby/lKwveQeI7+3VIBrJ1bHhLgqvIBccwTe4iXV4o1lcgGDXgo= =3NIb -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools/Distribute error with 0.7.2
I think it would be highly desirable to add support for pip to handle the upgrade from distribute 0.6 to 0.7. You'll note that because 0.7 depends on setuptools 0.7 that 0.7 has already been downloaded. Perhaps a shim like you propose would work, or it's also conceivable that distribute 0.7 could include a setuptools 0.7 source tree which pip could leverage (but not install). Yes, PEP 439 will be awesome, but I think this important milestone for setuptools is also essential to simplify the landscape in order to help migrate users in a sustainable way to the new tools, so we've got to find a way to make it happen for the good of the eco system. From: qwe...@gmail.com [mailto:qwe...@gmail.com] On Behalf Of Marcus Smith Sent: Sunday, 09 June, 2013 17:54 To: Jason R. Coombs Cc: Liam Kirsher; distutils-sig@python.org Subject: Re: [Distutils] Setuptools/Distribute error with 0.7.2 It was only working in python2 before now anyway. (https://github.com/pypa/pip/issues/650) pip is fundamentally dependent on setuptools to perform upgrades. with distribute-0.6.X upgrades, even though pip uninstalled distribute as part of the upgrade, it ran the install subprocess with the cwd equal to the build dir, so it could import setuptools from the unpacked download. but now, distribute-0.7 is just a shell, that contains no importable setuptools that pip can use. we could *make* it work I guess, by enforcing non-standard logic when dealing with distribute (i.e. get setuptools-0.7 installed first; by default, setuptools gets queued to be installed after the distribute upgrade) but like I said before, it's much more motivating to think about PEP439, than this dreary setuptools/distribute legacy headache stuff. Marcus the best fix I think is to move faster on making pip PEP439 compliant - i.e. have pip be able to at least install from wheels w/o needing setuptools, which would remove the bootstrap headache - see https://github.com/pypa/pip/issues/863 - this could likely involve pip replacing it's use of pkg_resources with distlib (https://github.com/pypa/pip/pull/909) Marcus smime.p7s Description: S/MIME cryptographic signature ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PyPI Download Counts
On 10 June 2013 06:04, Alex Clark acl...@aclark.net wrote: Donald Stufft donald at stufft.io writes: So yes. I broke Download counts because they were not more important than people being able to actually use PyPI to install from. FWIW: You missed the moral of the story: when you make a decision like this, someone will *always* disagree with you (even over the most trivial things). And even if they don't, they may disagree with your approach (e.g. why not sort problems with download counts before enabling the CDN) So the only way to make everyone happy is to consider everyone who will be affected by your actions, before you take action. And, indeed, we plan to run future changes of this magnitude through the PEP process for exactly this reason. We can't promise not to break some features in order to achieve gains we think are worth the loss, but we *can* promise not to break such features without advance warning and explicit consideration of alternatives that may allow us to avoid the breakage in the first place. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools/Distribute error with 0.7.2
On 10 June 2013 11:37, Jason R. Coombs jar...@jaraco.com wrote: I think it would be highly desirable to add support for pip to handle the upgrade from distribute 0.6 to 0.7. You’ll note that because 0.7 depends on setuptools 0.7 that 0.7 has already been downloaded. Perhaps a shim like you propose would work, or it’s also conceivable that distribute 0.7 could include a setuptools 0.7 source tree which pip could leverage (but not install). Yes, PEP 439 will be awesome, but I think this important milestone for setuptools is also essential to simplify the landscape in order to help migrate users in a sustainable way to the new tools, so we’ve got to find a way to make it happen for the good of the eco system. I believe Marcus's point was that if pip is using a vendored copy of distlib to do the installs (rather than relying on a separately installed instance of setuptools), then it would be able to upgrade/downgrade setuptools and distribute in both Python 2 and Python 3 without any dependency issues. On the other hand, a near-term special casing of distribute to force installing/upgrading setuptools 0.7 before upgrading distribute to 0.7 is likely a lower impact change to pip. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools 0.7.2 and Distribute 0.7 (compatibility wrapper) on PyPI
On 10 June 2013 03:49, Jason R. Coombs jar...@jaraco.com wrote: I'm leaning toward uploading it to BitBucket downloads as part of the release script. I'll put ez_setup.py for 0.7.2 in downloads for now. You can assume that's where the permalink will be. I think that's a good way to publish it securely to the PSF infrastructure team (at least for now) If anyone has a better suggestion, please raise it. As others have suggested, we should work with Donald and Noah to get the bootstrapping script an official home somewhere on pypi.python.org. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools/Distribute error with 0.7.2
agreed, a quick fix for the upcoming pip-1.4 would be nice. (PEP439 is 1.5 at best) here's the pip issue for this problem (set for 1.4) https://github.com/pypa/pip/issues/986 I'll discuss options in the issue. Marcus On Sun, Jun 9, 2013 at 6:37 PM, Jason R. Coombs jar...@jaraco.com wrote: I think it would be highly desirable to add support for pip to handle the upgrade from distribute 0.6 to 0.7. You’ll note that because 0.7 depends on setuptools 0.7 that 0.7 has already been downloaded. Perhaps a shim like you propose would work, or it’s also conceivable that distribute 0.7 could include a setuptools 0.7 source tree which pip could leverage (but not install). ** ** Yes, PEP 439 will be awesome, but I think this important milestone for setuptools is also essential to simplify the landscape in order to help migrate users in a sustainable way to the new tools, so we’ve got to find a way to make it happen for the good of the eco system. ** ** *From:* qwe...@gmail.com [mailto:qwe...@gmail.com] *On Behalf Of *Marcus Smith *Sent:* Sunday, 09 June, 2013 17:54 *To:* Jason R. Coombs *Cc:* Liam Kirsher; distutils-sig@python.org *Subject:* Re: [Distutils] Setuptools/Distribute error with 0.7.2 ** ** ** ** It was only working in python2 before now anyway. ( https://github.com/pypa/pip/issues/650) pip is fundamentally dependent on setuptools to perform upgrades. ** ** with distribute-0.6.X upgrades, even though pip uninstalled distribute as part of the upgrade, it ran the install subprocess with the cwd equal to the build dir, so it could import setuptools from the unpacked download.** ** but now, distribute-0.7 is just a shell, that contains no importable setuptools that pip can use. we could *make* it work I guess, by enforcing non-standard logic when dealing with distribute (i.e. get setuptools-0.7 installed first; by default, setuptools gets queued to be installed after the distribute upgrade) but like I said before, it's much more motivating to think about PEP439, than this dreary setuptools/distribute legacy headache stuff. ** ** Marcus ** ** the best fix I think is to move faster on making pip PEP439 compliant*** * - i.e. have pip be able to at least install from wheels w/o needing setuptools, which would remove the bootstrap headache - see https://github.com/pypa/pip/issues/863 - this could likely involve pip replacing it's use of pkg_resources with distlib (https://github.com/pypa/pip/pull/909) ** ** Marcus ** ** ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools 0.7.2 and Distribute 0.7 (compatibility wrapper) on PyPI
On Jun 9, 2013, at 9:51 PM, Nick Coghlan ncogh...@gmail.com wrote: On 10 June 2013 03:49, Jason R. Coombs jar...@jaraco.com wrote: I'm leaning toward uploading it to BitBucket downloads as part of the release script. I'll put ez_setup.py for 0.7.2 in downloads for now. You can assume that's where the permalink will be. I think that's a good way to publish it securely to the PSF infrastructure team (at least for now) If anyone has a better suggestion, please raise it. As others have suggested, we should work with Donald and Noah to get the bootstrapping script an official home somewhere on pypi.python.org. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig If you want it under pypi.python.org it'll probably need manually sent to myself for the time being. I believe it could easily be hosted via python hosted.org though without needing manual intervention. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools 0.7.2 and Distribute 0.7 (compatibility wrapper) on PyPI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/09/2013 10:28 PM, Donald Stufft wrote: On Jun 9, 2013, at 9:51 PM, Nick Coghlan ncogh...@gmail.com wrote: On 10 June 2013 03:49, Jason R. Coombs jar...@jaraco.com wrote: I'm leaning toward uploading it to BitBucket downloads as part of the release script. I'll put ez_setup.py for 0.7.2 in downloads for now. You can assume that's where the permalink will be. I think that's a good way to publish it securely to the PSF infrastructure team (at least for now) If anyone has a better suggestion, please raise it. As others have suggested, we should work with Donald and Noah to get the bootstrapping script an official home somewhere on pypi.python.org. If you want it under pypi.python.org it'll probably need manually sent to myself for the time being. I believe it could easily be hosted via python hosted.org though without needing manual intervention. I'm not wedded to anyplace in particular. Having the bootstrap needed to make effective use of PyPI hosted on PyPI itself makes a lot of sense to me. Maybe under a URL like this one? https://pypi.python.org/bootstraps/ez_setup.py The main key is that the URL should be immutable (so we can doucment it widely, and use it in scripts) and have availability as good as the cheeseshop (I'm not knocking Bitbucket in particular). If the file were copied into the Sphinx docs uploaded to pythonhosted.org, that would probably work just as well. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlG1PO8ACgkQ+gerLs4ltQ64WQCeO0tVhPBjlmzvtzdBx0C4V5Hr lVAAniVJ4XuAnPfV7NXT7KvcextrrTaJ =ILKd -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
