[openstack-dev] oslo.packaging progress - and comments?

Mark McLoughlin markmc at redhat.com
Mon Mar 18 08:26:34 UTC 2013


Hi Monty,

On Sun, 2013-03-10 at 21:58 -0400, Monty Taylor wrote:
> Hey guys!
> 
> I've been trying to figure out how to get openstack.common.setup out of
> openstack.common and in to a consumable library.

Nice!

> It's a non-trivial problem, because of the bootstrapping in setup.py.

Could you explain what the bootstrapping project is?

> Anyway - thanks to the d2to1 project, I've got it working. (yay!)
> 
> Here:
> https://review.openstack.org/#/c/24033/
> 
> is a work-in-progress patch showing what it's shaping up to look like
> for a project to consume this.

I've also tried it out for oslo.config:

https://github.com/markmc/oslo.config/commit/7e54a17

> The repo itself is up on github:
> 
> https://github.com/emonty/oslo-packaging

I've used filter-branch to clean up the history a bit:

https://github.com/markmc/oslo.packaging

> It still needs testing in tree, and it needs to be run through its paces
> and everything - but I wanted to get some stuff in front of people's
> eye-holes.
> 
> oslo.packaging above includes everything that's currently in
> openstack/common/setup, plus the speed-boost I just proposed.

Which speed-boost?

See below for a list of minor things I noticed looking over all this.

...

I like this new declarative metadata style in setup.cfg. The idea makes
a tonne of sense over supporting arbitrary code in setup.py that
generates metadata.

However, I'd much rather know that this is the way the entire python
world is going and eventually the standard setuptools stuff everyone is
using will support this.

So, I go digging ... there's d2to1[1] which supports distutils2[2]-like
setup.cfg files, but distutils2 got merged as 'packaging' during cpython
3.3 development but then got removed[3], distlib[4] has now entered the
scene and the metadata section in setup.cfg seems to be proposed by
pep390[5].

What took me so long to reply was trying to figure out all that, yet I'm
still not sure I fully understand the state of things.

What I'm wary of is us adopting some new fangled thing before the PEP on
it is even finalized. Heck, we're still on python 2.7 and this thingk
might not be officially blessed until 3.4.

If we release oslo.packaging with support for this setup.cfg metadata,
I'll want us to continue supporting the same format into the future. Any
change to the metadata supported by oslo.packaging would be a backwards
incompatible change.

Also, if we're going for this setup.cfg metadata, the only public API
exposed by oslo.packaging should probably just be setup_hook() rather
than all the functions in oslo.packaging.setup.

All of this leads me to wonder ... why should we make the leap to this
declarative metadata now? Why can't we do oslo.packaging without d2to1
and allow the distlib/pep390 saga settle down before we make the switch?

Cheers,
Mark.

* need https://github.com/iguananaut/d2to1/commit/0395d77 for dependency_links and tests_require
* set version to 1.1.0
* move tests under tests/ so they don't get installed
* need to include oslo.packaging in packages list
* can we avoid setuptools_git
* need to review which symbols are public so we can leave scope for future changes
* log.set_verbosity() on module import looks dodgy
* add license tag to setup.cfg
* doesn't seem to write namespace_packages.txt

[1] - https://github.com/iguananaut/d2to1
[2] - http://pythonhosted.org/Distutils2/
[3] - http://mail.python.org/pipermail/python-dev/2012-June/120430.html
[4] - https://readthedocs.org/projects/distlib/
[5] - http://www.python.org/dev/peps/pep-0390/




More information about the OpenStack-dev mailing list