Closed Bug 775243 Opened 8 years ago Closed 8 years ago
Create top-level directory for Python modules
I'm requesting that a new top-level directory be created in mozilla-central with the intention of holding all of the MPL-compatible Python packages and modules in the tree. What this is called is undecided. I'll throw out "python" and "pylib." I initially tried to do this starting in bug 754469 comment #5 but it flew under the radar. I figured I'd file a new bug to track just this issue. The context here is that currently we have a lot of Python support code scattered throughout the tree. The intention with creating a new top-level directory is to eventually unify all this code to one central, easy-to-find location. This will increase discovery and should hopefully lead to less duplication and better cohesion. It may even lead to higher quality since the increased visibility through unification may result in more consistency between in-tree code, making it easier to read and debug. I think we need a top-level directory because the Python in the tree is cross-module. We have bits for interacting with the build system, running tests, support tools, etc. I don't think there is a better place to put it. How bad is it currently? Just do a `find . -name '*.py'`. The following directories (and more) all need to be searched for Python modules at any given time: * build * build/pylib * build/pymake * config * dom * editor/libeditor/html/tests/browserscope/lib/richtext2 * ipc/ipdl * modules/freetype2/src/tools * testing/marionette * testing/mochitest * testing/mozbase/* (8 directories) * testing/peptest * testing/... * xpcom Filing a dummy review to Brendan because I'm told the buck stops there when it comes to creating a new top-level directory. If someone else wants to intercede, please do.
Attachment #643529 - Flags: review?(brendan)
I am +1 on python, as 'pylib' to me implies only library code, which may not be the case. A few more issues: * simplejson and virtualenv are in other-licenses, erroneously ABICT. These should definitely live here, and probably blessings too? (Not sure of its license). * Do we really want to move testing/ stuff to this directory? My inclination is no.
(In reply to Jeff Hammel [:jhammel] from comment #1) > A few more issues: > * simplejson and virtualenv are in other-licenses, erroneously ABICT. These > should definitely live here, and probably blessings too? (Not sure of its > license). According to Gerv, only things that are MPL incompatible go in other-licenses. Blessings is definitely MPL compatible and could be moved to this new directory immediately. simplejson and virtualenv appear to be MPL compatible. But, Gerv would need to sign off on moving those (we can track this in another bug). > * Do we really want to move testing/ stuff to this directory? My inclination > is no. I definitely think the mozbase stuff would move here if that is what you are talking about. Over time, I imagine a lot of the .py files (like the Python test runners or build system code in build/ and config/) would likely be rewritten as packages/modules during refactorings (because making things libraries is a generally good idea). At that time, they would be moved under the new top-level directory. Maybe they could be migrated sooner. But, that would generally be a low priority, I think.
As I just said in IRC, I think a decent analogy for this is "toolkit for Python." Not all Python would go here. But, the generic and reusable bits certainly could/should. Module owners would continue to be whoever owned the underlying bits, just like toolkit is a shared module today.
Comment on attachment 643529 [details] Is this OK? Sure. Just watch out not to slurp up and move anything unready for consolidation, or intentionally meant to be subsidiary and part of only one module. A README to say what mozilla/python is for would be good too. Thanks, /be
Attachment #643529 - Flags: review?(brendan) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/21f18a7f5f9d Thanks, Brendan! I wrote up a quick README in python/README that I believe accurately summarizes Brendan's comment and links back to this bug.
Assignee: nobody → gps
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla17
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.