Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
PLIP: get rid of bootstrap.py #2001
PLIP (Plone Improvement Proposal)
Proposer: Gil Forcada (@gforcada)
Seconder: Jens Klein (@jensens)
This is nowadays better solved with
It is 2017 and python, virtualenv and zc.buildout have improved a lot on the meantime, so it's time to say farewell to
The problems with bootstrap.py are:
Boostraping a project with
There is an agreement to remove
This discussion has been brought quite a few times, but given that Plone is going through quite a lot of major changes already (newer Zope, Python 3, all the JS/CSS major changes on Plone 5.x) it seems to be a good time to introduce yet another change, that while tiny (one does not bootstrap a project every day) it can be very frustrating if it does not work.
Proposal & Implementation
And extended proposal could be to create a small script that goes through all repositories in plone and collective github organizations and creates an issue if a
Pull requests to documentation repository with:
Pull requests to a few repositories to test against the porting guide (candidate repositories welcome)
The script to go through all repositories could most probably be suited to mr.roboto where it could even be made a bit more clever and only create issues on repositories that do have activity (there should no need to ping repositories long dead on collective org).
The main risk is to keep using
The only risk would be the introduction of a new way to do things, though, virtualenv has been around since forever and every developer that knows
The only main concern would be to have a time window where to test the new Jenkins setup before going live with it, although personally (@gforcada) I already have a Jenkins setup where virtualenv is used.
I agree to remove
But then it would be good to have a
It would be good to publish that file in
(And maybe a
@mauritsvanrees that sounds fine, but how are we supposed to distribute these two files? Should we mention them on the regular versions.cfg and also on the documentation?
About the files themselves:
Then the bootstraping should be(?):
For bootstrapping a buildout, you would only need the requirements file:
The constraints file would just be there to make it easier for people to for example try installing Plone with pip:
If the constraints file contains all our pins, then the buildout bootstrapping line could actually just be this:
I just checked: this also updates the installed
Ideally, buildout would be able to read a pip constraints or requirements file, so there is no duplication. Or it could be nice if it could output such a file.
If one or both files are on dist.plone.org, add-ons could download and use them in
@mauritsvanrees install plone with pip is still not supported though, right? Then, if I'm not mistaken, rather than a requirements.txt and constraints.txt, we only need constraints.txt, as one could only need to do:
Sorry if we're the only ones "complaining" about this PLIP, but we actually prefer buildout/buildout#289 and buildout/buildout#287 to settle down before doing this to all Plone packages, specially buildout/buildout#287 (comment), so we could try to make buildout/buildout#289 (comment) possible. Plone being able to be installed by pip would be the icying on the cake. @mauritsvanrees, did you really installed Plone using pip?
See how it all started: just "add a requirements.txt with setuptools and zc.buildout", and now we need appdirs, packaging, pyparsing and six as well and who knows what dependency in the future will needed to be added by setuptools. So if you have an "old" requirements.txt in your repository, today, it will possibly break in the future anyway as it would an old bootstrap.py. We're even talking about a constraints.txt...
IMHO, this is not simplifying bootstraping, it's adding another layer of complexity mixing up buildout and pip infrastructure. The same experienced user that can handle all the virtualenv insanity can get away with a problematic bootstrap.py as well.
For experienced Plone developers, yes; For new users (we're getting some of them getting in touch in community.plone.org in the last months), maybe not.
Please, don't get us wrong on this message, and sorry if it sounds "rude" (we don't mean it): we just thought that a contrary opinion would be useful, at least for historical record (or we can even change our minds).
exactly, we're going to get rid of one file (bootstrap.py) just to add 2 new files to every package (requirements.txt and constraints.txt) and this is going to be worse next time we find an issue.
besides that, what problem are we solving? all the isolation code was removed from Buildout 2 anyway.
it's too early: we have to wait for consensus on the Buildout world before moving on any direction.
I know at least, that @do3cc has one 4.3 installed woth pip inside a docker container, which afaik was a PITA because the infrastructure is not there.
Don't get me wrong, this PLIP does not aim to be the full story but the beginning of one.
I know you folks would love always to get the full feature at once. It's usually not possible in a community driven world, except if members make it happen! In this case I prefer to have small steps working instead a vision nobody is able to invest time in. We can do this right now and then improve upon it.
It is true, I have a Plone 4.3 site that I install with pip only. It is not a pita for me, I am really happy with it.
But this proposal is only about replacing
There is only one reason that buildout/buildout#289 isn't closed. Changing the tests after the doc changes is a lot of work. I gave up after a few hours.
I saw two complaints here:
Using constraints.txt, if I want to debug something and play with dependencies and it's versions, I'll have to think: is this package installed with pip or buildout? Remove it from eggs or run a
The problem here is not just "they both become outdated", you have now two ways of doing the same thing. "Hey, don't forget to use virtualenv, so you can have an isolated buildout instance with your own polluted site-packages that you'll have to figure it out by yourself when you shoot yourself in the foot". In the beginning, we only had
Like @hvelarde said, we'll follow you, it doesn't mean we agree with that.
I tried something with an experimental recipe, but ran into problems with
I would be in favour of using a
I can image a buildout extension that reads pinned versions from
By default this would not override versions from the
referenced this issue
Apr 28, 2017
after spending the whole morning trying to set up a new worker in jenkins
sorry but bootstrap.py is totally broken with current buildout.coredev 5.1: bootstrap.py and latest setuptools and latest zc.buildout don't play together at all.
The same bootstraping problem I still haven't solved was just a 5 commands with a virtualenv and pip installing zc.buildout and setuptools.
Up until recently, as @mauritsvanrees mentions with the newer dependencies of setuptools, it was mostly possible to keep using bootstrap.py, but if you have a completely empty environment... good luck.