dh_python2 and /usr/share/pyshared in quantal

[Barry Warsaw]

On May 23, 2012, at 09:49 AM, Matthias Klose wrote:

>On 22.05.2012 23:42, Scott Kitterman wrote:
>> /usr/share/pyshared is the correct location for such things.  That's what 
>> Python policy says.  pyshared is not an internal implementation detail of 
>> dh_python2.  It's where Python policy says to find such things.
>
>that is plain wrong. pyshared *is* an implementation detail for the working of
>the package. Every package having pyshared on sys.path for testing, building,
>installation is buggy.
>
>So i'll modify the interpreter do disallow imports from pyshared to catch
>exactly these misuses.

Before you do this, I think some groundwork needs to be laid.  First, you need
to get general consensus that eradication of pyshared is a goal to be
achieved.  You don't need (and won't get) 100% consensus, but I think you need
the majority of developers to agree that this is a goal, and to commit to
helping make this happen.  The debian-python mailing list is the right place
to have this discussion.  Without consensus, bugs will just get Won't Fixed
and/or Ubuntu will just carry even more deltas from Debian, which I think we
all agree is not good.

(Take the dh_python2 transition as a model.  We didn't get - and still don't
have - 100% agreement about it, but we got a majority of developers to agree
that it was the right thing to do, and with official deprecation of
python-central and python-support, it became the defacto standard helper for
Python 2.  These facts can be used in bug reports, patches, wiki pages, and
other means of communication to rally developers around the transition.
Ubuntu can still lead, but it makes it easier to push patches back to Debian,
with reasonable justification, so that you only have to route around the small
number of holdouts.  And yes, we decided that it was important enough for us
to carry deltas and pay the ongoing cost for those holdouts.)

Part of that consensus must include appropriate updates to python-policy so
that we have documented best practices that other developers can refer to.
Also, you need transition guidelines so that developers who want to conform to
the new standards know what changes to make to their packages.  This
information is also useful to contributors who want to help with the
transition.

(We had *a lot* of external contributions for the dh_python2 transition, and
having a wiki page with very clear instructions was immensely helpful for
everyone involved.)

Once consensus is reached, I think you also need a plan for achieving the
goal.  Just breaking packages isn't good enough because the people who will
suffer will be our users, who probably can't fix the problem themselves.  How
will violations be tracked?  Will you just leave it up to users to file bugs?
How to be sure that those bugs are appropriately triaged to be caused by
pyshared import violations?  What's the plan for getting those fixed?  Again,
even if you can find 100% of those violations, you need a way to follow up to
make sure the change doesn't just result in a stack of bugs that never get
looked at or fixed.

Can you use a less drastic strategy for achieving your goal?  If prohibiting
pyshared imports really is the only way, I'd definitely want to do a code
review on the implementation, just to be sure it doesn't have unintended
side-effects.

So maybe this doesn't affect nearly as many packages, but I still think you
need a little more planning before taking the hard-line step of prohibiting
imports.

Cheers,
-Barry