Closed aclark4life closed 6 years ago
The docs/INSTALL.rst
mentions a different way:
$ /usr/bin/python bootstrap.py
$ ./bin/buildout
I'm not sure whether or not those are preferable to your way. But at least we should recommend the same approach in both places. Given how short the install docs are, I'm not sure if there's a need for a quickstart section in the main docs.
OK I think a good compromise would be to agree on the quick start, and then add it to the README.rst
. Hopefully no one wants to argue that it shouldn't be included in the README.rst
(I don't ever want to read docs/INSTALL.txt
unless I have to.)
But in order to do that, we need to go down a few rabbit holes and discuss a few bike shed colors first:
python2.7 bootstrap.py; bin/buildout
or python2.7 bootstrap.py; ./bin/buildout
.bootstrap.py
but when it's used, is it safe to assume that it picks the right setuptools and zc.buildout versions in all cases and that "Installing setuptools…" loops never occur? IIRC, I arrived at my current approach after being burned by bootstrap.py
one too many times.virtualenv
fit in? It feels natural to me to create and work in a virtualenv when using zc.buildout
but are we recommending that to everyone? (I don't want to read docs/INSTALL.txt
to find out, if possible.)Thanks for considering.
I am okay with having a quickstart section. We could merge INSTALL.rst
(and UPGRADE.rst
) into README.rst
entirely, but it may start to be confusing with all the sub headers. So quickstart is okay for me.
But I would keep the quickstart the same as in the install docs: use bootstrap.py
. Otherwise you use the system python to create a virtualenv and then a virtualenv to create a new python, and you are three levels deep; and then you use this python to create more virtualenvs or buildouts. It's turtles all the way down, not Pythons. ;-)
Virtualenv will probably work fine here, and for many buildouts I am slowly switching to it, but for this case I am inclined to keep the tried and true bootstrap.py
method with the ancient setuptools
and zc.buildout
versions, also because this Python buildout may be run on ancient systems which by themselves only have a Python 2.4 and would not be able to get a recent virtualenv or setuptools running.
The virtualenv way could be added under an 'Alternative' sub header in INSTALL.rst
. Would that work for you?
@mauritsvanrees Yup, fine to keep bootstrap.py
. Can anyone confirm that the bootstrap.py
always successfully installs the "ancient versions" of setuptools
and zc.buildout
? I think we should document those versions in the Quick Start too. (1.4.2 and 1.7.1 respectively, IIRC)
'always' successfully installing might be a bit optimistic. For example it currently fails because PyPI no longer serves http. I will do a pull request soon.
Instead of zc.buildout 1.4.2, I would say 1.4.4.
Note that the python
in python bootstrap.py
may need to be Python 2.7 or higher. At least I wish anyone who want to use Python 2.4 for bootstrapping good luck in hand crafting an ez_setup.py
that works for that Python version... (It is probably doable, but I don't want to do it.)
@mauritsvanrees zc.buildout==1.7.1
and setuptools==1.4.2
@mauritsvanrees zc.buildout==1.7.1 and setuptools==1.4.2
Ah, right, that is a good combination.
Doesn't using zc.buildout 1.7.1 conflict with this line? https://github.com/collective/buildout.python/blob/master/src/base.cfg#L16
Doesn't using zc.buildout 1.7.1 conflict with this line? https://github.com/collective/buildout.python/blob/master/src/base.cfg#L16
Ah, true, we pin zc.buildout
to 1.4.4. That is because of some issues with later buildout versions, but 1.7.1 was released after the last comment in that issue. I suspect 1.7.1 would be fine (1.5 was the one that gave the most problems), and that would mean updating the pin in the file you point to.
But 1.4.4 is fine too.
OK, well, in case it's not clear:
E.g. If I follow the install instructions, I get this:
Additionally my quick start now fails with:
~/Developer/buildout/buildout.python > master > bin/buildout
Couldn't find index page for 'buildout.extensionscripts' (maybe misspelled?)
Getting distribution for 'buildout.extensionscripts'.
While:
Installing.
Loading extensions.
Getting distribution for 'buildout.extensionscripts'.
Error: Couldn't find a distribution for 'buildout.extensionscripts'.
Is this due to some SSL changes on PyPI?
Yes. We would need to add index = https://pypi.python.org/simple
in the buildout
section. This was not needed a couple of weeks ago.
@aclark4life the buildout was originally and mainly for OS X, so /usr/bin/python
refers to it's system python. The idea is/was that the buildout can be bootstrapped without installing too much other stuff. I think installing the XCode command line tools should be enough to get a working Python. For some modules one might need to install some libs with homebrew or something similar.
This is how I've always installed
buildout.python
and I'd like to document these steps somewhere.