Refactor options bootstrapping.

Review Request #1453 - Created Dec. 9, 2014 and submitted

Information
Benjy Weinberger
pants
4731cb9...
Reviewers
pants-reviews
jsirois, patricklaw, zundel

Instead of free-floating functions, the bootstrapping is now
encapsulated in a bootstrapper class. This class exposes both the
bootstrap and full options.

This is necessary to support the startup sequence in pants_exe.py properly:

- To create full options we need the known scopes.
- To get the known scopes we need to load plugins and extensions.
- The plugin and extension registration code may use config.

Therefore we need a way to load the bootstrap config, then do some work,
then load the full options.

Currently we achieve this with a gross manual config-reading hack in pants_exe.py.
This change will allow us to get rid of that hack.

This change also fixes an issue where in tests the buildroot wasn't plumbed in
everywhere it should be.

Unit tests pass. Integration tests pass.

Benjy Weinberger
John Sirois
John Sirois
Benjy Weinberger
Review request changed

Status: Closed (submitted)

Change Summary:

Submitted as a3b2f2ab21d1d16e58213973e59049d755374db1.
John Sirois

This may be coincidental, but our builds have been red since this landed: https://travis-ci.org/pantsbuild/pants/builds
python3.2 has crept back in to the interpreters being selected from raising errors for unicode literals. The --interpreter arguments used by the ci.sh script are global options which are tied up in the bits this RB touched so I'm leaning towards not coincidence.

  1. I think the "<buildroot>" here is text intended for use in the online help. I ?think? we don't want to use it as part of a real path.

         **** Failed to install wheel-0.23.0. stderr:
                       File "<stdin>", line 2
                         sys.path.insert(0, u'/home/travis/build/pantsbuild/pants/<buildroot>/.pants.d/python/interpreters/CPython-3.2.5/setuptools-5.4.1-py3.2.egg'); import setuptools
                                                                                                                                                                   ^
                     SyntaxError: invalid syntax
    
  2. ...but I don't see "<buildroot>" in many places in the log, so this is probably not the real problem. Sorry for the noise.

  3. No - I think it is. A slight bit of handwave but see here: https://github.com/pantsbuild/pants/blob/master/pants.ini#L195 and note that the bootstrapping code sets cached Config. If the cached config used by the pants test runner were not to have the interpreter constraints present in pants.ini - we'd pick up python3.2.

    Thanks for looking! I'll try a quick adjustment to ci.sh to pass explicit --interpreter flags to the test run like it used to to work around - If that gets things green - this code can be revisited if it even needs to be - the caching is a temp hack as I recall.

  4. Still fuzzy on this but I have a fix in unrelated code I'm working on.

  5. Still under CI - but https://rbcommons.com/s/twitter/r/1463/

    Sorry for the trigger finger suspecting this RB. I'm still not clear why this popped up for this review.

John Sirois

   

This was the problem. OptionsBootstrapper mutates global Config._default values in its constructor and unlike the BootstrapOptionsTest this mutation was not reset. I have a fix coming shortly.

Loading...