oslo.config egg doesn't contain namespace_packages.txt

Bug #1194742 reported by Mark McLoughlin
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
PBR
Fix Released
Critical
Monty Taylor
oslo-incubator
Fix Released
Critical
Monty Taylor

Bug Description

Credit to Alan Pevec for noticing this

If you do 'python setup.py egg_info', notice that there is no namespace_packages.txt file written out

This is despite setup.cfg containing:

 [files]
 packages =
     oslo
 namespace_packages =
     oslo

Seems pretty clear that d2to1 doesn't actually support this:

  https://github.com/iguananaut/d2to1/blob/5a1c80b2/d2to1/util.py#L47

This seems like it's a pretty serious issue, but I don't actually know what the implications are ... is it that without this namespace_packages.txt, we'd get oslo/__init__.py installed and this would conflict with any other packages which want to install into this namespace?

Revision history for this message
Alan Pevec (apevec) wrote :

> we'd get oslo/__init__.py installed and this would conflict with any other packages which want to install into this namespace?

yes:

* python-oslo-config-1:1.1.0-1.fc20
 http://koji.fedoraproject.org/koji/rpminfo?rpmID=3818867

* python-oslo-config-1:1.2.0-0.1.a2.fc20
 http://koji.fedoraproject.org/koji/rpminfo?rpmID=4101838

Revision history for this message
Mark McLoughlin (markmc) wrote :

Monty says he's on it

Changed in pbr:
status: New → Triaged
importance: Undecided → High
assignee: nobody → Monty Taylor (mordred)
Revision history for this message
Mark McLoughlin (markmc) wrote :

Monty has proposed this fix to d2to1 : https://github.com/iguananaut/d2to1/pull/32

Revision history for this message
Mark McLoughlin (markmc) wrote :

2013-06-26T15:52:42 <markmc> mordred, I see you've some pull requests sitting there for some months :(
2013-06-26T15:53:02 <mordred> markmc: yeah, that's why I pinged him directly
2013-06-26T15:56:31 <mordred> markmc: just got a response, he's been on vacation for a few weeks and is working through post-vacation email backlog
2013-06-26T15:56:43 <mordred> markmc: but he's going to bump that patch to the top of the list

Revision history for this message
Monty Taylor (mordred) wrote :

Workaround until the above fix is landed and released:

namespace_packages = ['oslo'],

into setup.py directly.

Revision history for this message
Mark McLoughlin (markmc) wrote :

See also bug #1194807 ... as we said, they could be related

Changed in oslo:
importance: High → Critical
Changed in pbr:
importance: High → Critical
Revision history for this message
Mark McLoughlin (markmc) wrote :

Here's Monty's attempt to fix this - https://review.openstack.org/34586

It fails with: error in setup command: Distribution contains no modules or packages for namespace package 'oslo'

There's a good chance neither Monty nor I will be able to look at this much today, so any help figuring out the issue would be welcome.

Changed in oslo:
assignee: nobody → Monty Taylor (mordred)
status: Triaged → In Progress
Revision history for this message
Doug Hellmann (doug-hellmann) wrote :

I updated the patch this morning. It looks like specifying the packages in setup.py fixes the problem. There's probably a check being done to the settings before d2to1 has a chance to inject the values from setup.cfg, which should be taken care of when we get the namespace_package setting injection working properly.

Revision history for this message
Mark McLoughlin (markmc) wrote :

Much appreciated Doug, you're the man

Changed in oslo:
status: In Progress → Fix Committed
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to oslo-incubator (master)

Fix proposed to branch: master
Review: https://review.openstack.org/35280

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to oslo-incubator (master)

Reviewed: https://review.openstack.org/35280
Committed: http://github.com/openstack/oslo-incubator/commit/9f09474c5f8f591453e1dc5e3c1ddc3c7efd4985
Submitter: Jenkins
Branch: master

commit 9f09474c5f8f591453e1dc5e3c1ddc3c7efd4985
Author: Mark McLoughlin <email address hidden>
Date: Tue Jul 2 13:01:26 2013 +0100

    Fix issue with pip installing oslo.config-1.2.0

    Fixes bug #1194807

    Firstly, we update the oslo.config dep to 1.2.0a3 because of the issue
    with namespace packages (bug #1194742).

    But the main issue here is that if we ever added a dependency to our
    requirements.txt that had a dependency on an older version of
    oslo.config we would see the same issue thatt Nova and Quantum recently
    experienced where you end up with the oslo.config 1.1.1 code installed.
    This is because oslo.config>=1.1.0 gets pulled in as a transitive dep
    and pip gets confused. You can reproduce with e.g.

      $> pip install \
           http://.../oslo.config-1.2.0a3.tar.gz#egg=oslo.config-1.2.0a3 \
           python-keystoneclient
      $> pip freeze | grep oslo.config
      oslo.config-1.2.0a3
      $> python -c 'from oslo.config.cfg import DeprecatedOpt'
      Traceback (most recent call last):
        File "<string>", line 1, in <module>
      ImportError: cannot import name DeprecatedOpt

    This is because of a bug with pip where it sees oslo.config-1.2.0a3 and
    oslo.config as two unrelated things. It should strip the version part of
    the egg= fragment before using it as a package name, but it doesn't.

    However, we can simply use the -f/--find-links pip option in our
    requirements.txt to add the tarball URL to the list of URLs considered
    and also add the oslo.config>=1.2.0a3 dependency:

      $> pip install \
           -f http://.../oslo.config-1.2.0a3.tar.gz#egg=oslo.config-1.2.0a3 \
           'oslo.config>=1.2.0a3' \
           python-keystoneclient
      $> pip freeze | grep oslo.config
      oslo.config-1.2.0a3
      $> python -c 'from oslo.config.cfg import DeprecatedOpt'

    This is actually exactly the semantics we want and we go to great
    lengths in pbr to get these semantics while using a single tarball URL.
    The only downside to this --find-links strategy is that we gain an extra
    line in our requirements.txt ... but it does work around the pip bug.

    Change-Id: I6f3eb5fd2c75615d9a1cae172aed859b36b27d4c

Thierry Carrez (ttx)
Changed in oslo:
status: Fix Committed → Fix Released
Monty Taylor (mordred)
Changed in pbr:
status: Triaged → Fix Released
Thierry Carrez (ttx)
Changed in oslo:
milestone: havana-2 → 2013.2
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.