[Distutils] Merging forks
Something prompted by the setuptools merge, and its impact on pip. Does Python's packaging metadata need a way of declaring in a package that it is a merge of (two or more) other packages? Obviously this is a rare scenario, but it's painful when it occurs (how can a tool know that setuptools 0.7 is a later version of distribute than 0.6.36?) Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] buildout 1 still not managing to pin buildout to 1.x
On 10/06/2013 18:57, Tres Seaver wrote: Works for me: $ mkdir /tmp/withers $ cd /tmp/withers $ echo [buildout] parts = buildout.cfg $ wget http://downloads.buildout.org/1/bootstrap.py ... $ /opt/Python-2.5.x/bin/python bootstrap.py Try with 2.7, and also try going from 1 to 2 and back again by switching bootstraps. There's likely something funky going on (.installed.cfg, develop-eggs or some other goat sacrifice in bin/) but it definitely happened. 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] Merging forks
On Jun 11, 2013, at 4:46 AM, Paul Moore p.f.mo...@gmail.com wrote: Something prompted by the setuptools merge, and its impact on pip. Does Python's packaging metadata need a way of declaring in a package that it is a merge of (two or more) other packages? Obviously this is a rare scenario, but it's painful when it occurs (how can a tool know that setuptools 0.7 is a later version of distribute than 0.6.36?) Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig http://www.python.org/dev/peps/pep-0426/#obsoleted-by - 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] b.pypi.python.org
OK, http://www.pypi-mirrors.org is now reporting b.pypi.python.org as N/A which I believe means the DNS propagation is complete. We can move on to phase 2 and use Brett's trick to switch to serving 404's for everything for a little while (how long?) and then fully turn off the app. Ken On Sun, 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. --Noah ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] buildout 1 still not managing to pin buildout to 1.x
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/11/2013 05:27 AM, Chris Withers wrote: On 10/06/2013 18:57, Tres Seaver wrote: Works for me: $ mkdir /tmp/withers $ cd /tmp/withers $ echo [buildout] parts = buildout.cfg $ wget http://downloads.buildout.org/1/bootstrap.py ... $ /opt/Python-2.5.x/bin/python bootstrap.py Try with 2.7, and also try going from 1 to 2 and back again by switching bootstraps. There's likely something funky going on (.installed.cfg, develop-eggs or some other goat sacrifice in bin/) but it definitely happened. That same recipe works with 2.7. In general, the presence of .installed.cfg should be thought of as problematic for any big surgery (like changing bootstraps, or major versions of buildout), because it hampers repeatability in order to make the build run faster. When in doubt, remove .installed.cfg and re-run buildout after any such change. 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/ iEYEARECAAYFAlG3sSMACgkQ+gerLs4ltQ4ExACfaXdJ1n3jFV+W0HmuNuKB1SDN 8W0Anj3WVTQebSJ71K1Q488KCr5JK/gd =NsB8 -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] buildout 1 still not managing to pin buildout to 1.x
On Tue, Jun 11, 2013 at 7:22 PM, Tres Seaver tsea...@palladion.com wrote: When in doubt, remove .installed.cfg and re-run buildout after any such change. So the real question is: Why doesn't bootstrap.py just do this? I've stumbled on this many times as well; I don't see an advantage to this not being handled by the bootstrap, because it will surprise us eventually. Some of us (include me, apparently) are more easily surprised than others. -Fred -- Fred L. Drake, Jr.fred at fdrake.net A storm broke loose in my mind. --Albert Einstein ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] buildout 1 still not managing to pin buildout to 1.x
On Tue, Jun 11, 2013 at 7:22 PM, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/11/2013 05:27 AM, Chris Withers wrote: On 10/06/2013 18:57, Tres Seaver wrote: Works for me: $ mkdir /tmp/withers $ cd /tmp/withers $ echo [buildout] parts = buildout.cfg $ wget http://downloads.buildout.org/1/bootstrap.py ... $ /opt/Python-2.5.x/bin/python bootstrap.py Try with 2.7, and also try going from 1 to 2 and back again by switching bootstraps. There's likely something funky going on (.installed.cfg, develop-eggs or some other goat sacrifice in bin/) but it definitely happened. That same recipe works with 2.7. In general, the presence of .installed.cfg should be thought of as problematic for any big surgery (like changing bootstraps, or major versions of buildout), because it hampers repeatability in order to make the build run faster. No. It is not an optimization. It's there to know what needs to be uninstalled. It's often OK to just remove it. but by doing so you're forgoing cleanup. It would be better to uninstall everything with the old buildout: bin/buildout buildout:parts= Before removing the installed file. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] buildout 1 still not managing to pin buildout to 1.x
On Tue, Jun 11, 2013 at 7:48 PM, Fred Drake f...@fdrake.net wrote: On Tue, Jun 11, 2013 at 7:22 PM, Tres Seaver tsea...@palladion.com wrote: When in doubt, remove .installed.cfg and re-run buildout after any such change. So the real question is: Why doesn't bootstrap.py just do this? Because it's not just an optimization and removing .installed.cfg prevents cleanup that might be desirable. Removing it as part of bootstrap seems too magic for me. I'd rather: - Error if there's a .installed.cfg - adding a --force option that tries to uninstall and then removed .instaled.cfg. I've stumbled on this many times as well; I don't see an advantage to this not being handled by the bootstrap, because it will surprise us eventually. It rarely surprises me. Some of us (include me, apparently) are more easily surprised than others. No kidding. ;) Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
