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 -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
