Towards a bandersnatch release - updates, PIP, contacting mirror owners
Hi, I spend some more time on bandersnatch and I'm ready for a stable release, I guess. Updates ------------ * Add a specific user agent to XML-RPC and plain HTTP calls * Add a specific user agent to the logging to support debugging * Provide a default (10s) network timeout and a config option to customize * Clean up README PIP --- I'd be happy to cut a release now. Holger Krekel asked me whether I could ensure that bandersnatch is pip installable. Looking through the PIP documentation I don't see how I can make a simple "pip install bandersnatch" repeatable. Especially if someone would run a public mirror I would prefer if they would use an installation method that makes their deployment repeatable. From my own experience and background I would prefer buildout in the following style: $ hg clone https://bitbucket.org/ctheune/bandersnatch $ cd bandersnatch $ hg co 1.0 $ virtualenv-2.7 . $ bin/python bootstrap.py $ bin/buildout $ bin/bandersnatch Thoughts? Contacting mirror owners ---------------------------------- All this work is directed towards getting the existing official mirrors back to a "green bar" situation soon. Can someone help me contact the existing mirror owners to convince them to switch tools? Also, I'd be happy to run a couple vhosts around the world to extend the network if some people throw in some money (gittip?) Cheers, Christian
On 8 April 2013 06:43, Christian Theune <ct@gocept.com> wrote:
Hi,
I spend some more time on bandersnatch and I'm ready for a stable release, I guess.
Updates ------------
* Add a specific user agent to XML-RPC and plain HTTP calls * Add a specific user agent to the logging to support debugging * Provide a default (10s) network timeout and a config option to customize * Clean up README
PIP ---
I'd be happy to cut a release now. Holger Krekel asked me whether I could ensure that bandersnatch is pip installable. Looking through the PIP documentation I don't see how I can make a simple "pip install bandersnatch" repeatable.
Especially if someone would run a public mirror I would prefer if they would use an installation method that makes their deployment repeatable. From my own experience and background I would prefer buildout in the following style:
$ hg clone https://bitbucket.org/ctheune/bandersnatch $ cd bandersnatch $ hg co 1.0 $ virtualenv-2.7 . $ bin/python bootstrap.py $ bin/buildout $ bin/bandersnatch
Thoughts?
You can make it pip installable without breaking buildout; then folk can choose themselves. Environments that are pip based will have a harder time with more waste if you insist on buildout being the one true way for your tool. -Rob -- Robert Collins <rbtcollins@hp.com> Distinguished Technologist HP Cloud Services
Hi Christian, On Sun, Apr 07, 2013 at 20:43 +0200, Christian Theune wrote:
Hi,
I spend some more time on bandersnatch and I'm ready for a stable release, I guess.
Updates ------------
* Add a specific user agent to XML-RPC and plain HTTP calls * Add a specific user agent to the logging to support debugging * Provide a default (10s) network timeout and a config option to customize * Clean up README
PIP ---
I'd be happy to cut a release now. Holger Krekel asked me whether I could ensure that bandersnatch is pip installable. Looking through the PIP documentation I don't see how I can make a simple "pip install bandersnatch" repeatable.
Especially if someone would run a public mirror I would prefer if they would use an installation method that makes their deployment repeatable. From my own experience and background I would prefer buildout in the following style:
$ hg clone https://bitbucket.org/ctheune/bandersnatch $ cd bandersnatch $ hg co 1.0 $ virtualenv-2.7 .
As to installability, why not: $ bin/python setup.py install $ bin/bandersnatch now? You'd need to import from setuptools instead of distutils to get the install_requires=[dep1,dep2,...] metadata interpreted correctly. Also, uploading a 1.0 release to pypi would allow to say "pip install bandersnatch" instead of getting the hg repo and the setup.py install command. cheers, holger
$ bin/python bootstrap.py $ bin/buildout $ bin/bandersnatch
Thoughts?
Contacting mirror owners ----------------------------------
All this work is directed towards getting the existing official mirrors back to a "green bar" situation soon. Can someone help me contact the existing mirror owners to convince them to switch tools?
Also, I'd be happy to run a couple vhosts around the world to extend the network if some people throw in some money (gittip?)
Cheers, Christian
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
On Sun 07 Apr 2013 04:01:07 PM EDT, holger krekel wrote:
interpreted correctly. Also, uploading a 1.0 release to pypi would allow to say "pip install bandersnatch" instead of getting the hg repo and the setup.py install command.
I agree, a PyPI package would make it easy for pip users.
On 2013-04-08 01:09:44 +0000, Trishank Karthik Kuppusamy said:
On Sun 07 Apr 2013 04:01:07 PM EDT, holger krekel wrote:
interpreted correctly. Also, uploading a 1.0 release to pypi would allow to say "pip install bandersnatch" instead of getting the hg repo and the setup.py install command.
I agree, a PyPI package would make it easy for pip users.
Making an sdist and uploading it to PyPI isn't what I have trouble with: The installation instructions that I provide are intended to help people operate (public) mirrors. I want to make it as smooth as possible and will likely have to respond to support requests when people have problems getting set up etc. One of the biggest issues doing a service deployment is to get the dependency versions right. Fixing all versions in setup.py is too inflexible and I personally am happy with the way buildout solves this. I would be happy to support a pip installation *if* I can make instructions that are as straight forward as the ones I'm giving for buildout and end up in people having predictable installations. "pip install bandersnatch" will result in whatever dependency versions people happen to get. "pip install -r http://bitbucket.org/.../requirements.txt" is just close to the hellish "curl | bash". Again: I'd be happy to support people if they prefer PIP for installation. Using a requirements.txt file I don't see much improvement from the "virtualenv, get the file, run it". Doing that with a tagged Mercurial checkout + buildout at least lets you catch up to newer releases more smoothly, no? Regards, Christian
Hi, On 2013-04-08 01:09:44 +0000, Trishank Karthik Kuppusamy said:
On Sun 07 Apr 2013 04:01:07 PM EDT, holger krekel wrote:
interpreted correctly. Also, uploading a 1.0 release to pypi would allow to say "pip install bandersnatch" instead of getting the hg repo and the setup.py install command.
I agree, a PyPI package would make it easy for pip users.
I think I made a mistake (by omission) when phrasing my question, sorry, let me try to clarify: I'm not asking whether I should upload a pip/distribute/easy_install/buildout-compatible package (sdist) to PyPI. That's the easy part. As I have not used pip seriously before, I'm wondering how people document service setups for pip users that are repeatable, i.e. where all dependency versions will be fixed. I think the verdict on fixing versions in setup.py was passed a few years ago (correctly), so I think pip uses requirements.txt files for this. How do you guide pip users to install a service (not a library) this way? AFAICT a changed installation instruction would look like this: $ virtualenv-2.7 bandersnatch $ cd bandersnatch $ wget http://someserver/bandersnatch-1.0/requirements.txt $ bin/pip install -r requirements.txt This doesn't look too different from my current approach, except that you download a (versioned) requirements.txt file instead of getting a checkout. Whether you run $ bin/python bootstrap.py; bin/buildout or $ bin/pip install -r requirements.txt Doesn't make too much of a difference to me. In contrast: running from an HG clone gives easier ugprades, actually. Again, I'm trying to understand why people want to do it this way and I'm happy to do some extra work in order to learn something. What am I missing? Christian
Hello Christian, On 04/08/2013 09:09 AM, Christian Theune wrote:
As I have not used pip seriously before, I'm wondering how people document service setups for pip users that are repeatable, i.e. where all dependency versions will be fixed.
I think the verdict on fixing versions in setup.py was passed a few years ago (correctly), so I think pip uses requirements.txt files for this.
How do you guide pip users to install a service (not a library) this way?
AFAICT a changed installation instruction would look like this:
$ virtualenv-2.7 bandersnatch $ cd bandersnatch $ wget http://someserver/bandersnatch-1.0/requirements.txt $ bin/pip install -r requirements.txt
This doesn't look too different from my current approach, except that you download a (versioned) requirements.txt file instead of getting a checkout. Whether you run
$ bin/python bootstrap.py; bin/buildout
or
$ bin/pip install -r requirements.txt
Doesn't make too much of a difference to me. In contrast: running from an HG clone gives easier ugprades, actually.
Again, I'm trying to understand why people want to do it this way and I'm happy to do some extra work in order to learn something.
What am I missing?
I don't think you're really missing anything, except that for some people pip is familiar and comfortable and buildout is not. And these people may want to manage their deployment using existing infrastructure (e.g. Chef/Puppet recipes) that relies on having a requirements.txt file, making the two options not so equivalent as they seem to you. For instance, if someone wanted to deploy bandersnatch to the Heroku platform-as-a-service without writing a custom build-pack, they would not even be running either of the commands above themselves, they would need to provide a requirements.txt file to Heroku. I don't think this would need to be a particularly complex change on your part; just upload the sdist, provide a requirements.txt file with exactly-pinned dependencies for each bandersnatch version, and note its existence as a second option in your installation instructions. Carl
participants (5)
-
Carl Meyer -
Christian Theune -
holger krekel -
Robert Collins -
Trishank Karthik Kuppusamy