collective / buildout.python

Buildout all the Pythons
109 stars 47 forks source link

Fix install instructions #67

Closed aclark4life closed 6 years ago

aclark4life commented 7 years ago

This is how I've always installed buildout.python and I'd like to document these steps somewhere.

hannosch commented 7 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.

aclark4life commented 7 years ago

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:

Thanks for considering.

mauritsvanrees commented 7 years ago

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?

aclark4life commented 7 years ago

@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)

mauritsvanrees commented 7 years ago

'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.)

aclark4life commented 7 years ago

@mauritsvanrees zc.buildout==1.7.1 and setuptools==1.4.2

mauritsvanrees commented 7 years ago

@mauritsvanrees zc.buildout==1.7.1 and setuptools==1.4.2

Ah, right, that is a good combination.

adamcheasley commented 7 years ago

Doesn't using zc.buildout 1.7.1 conflict with this line? https://github.com/collective/buildout.python/blob/master/src/base.cfg#L16

mauritsvanrees commented 7 years ago

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.

aclark4life commented 6 years ago

OK, well, in case it's not clear:

E.g. If I follow the install instructions, I get this:

screenshot 2017-11-30 08 16 36
aclark4life commented 6 years ago

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?

mauritsvanrees commented 6 years ago

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.

fschulze commented 6 years 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.