Last Comment Bug 775243 - Create top-level directory for Python modules
: Create top-level directory for Python modules
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: General (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla17
Assigned To: Gregory Szorc [:gps]
:
Mentors:
Depends on:
Blocks: 775756 777068
  Show dependency treegraph
 
Reported: 2012-07-18 12:51 PDT by Gregory Szorc [:gps]
Modified: 2012-07-25 08:11 PDT (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Is this OK? (19 bytes, text/plain)
2012-07-18 12:51 PDT, Gregory Szorc [:gps]
brendan: review+
Details

Description Gregory Szorc [:gps] 2012-07-18 12:51:14 PDT
Created attachment 643529 [details]
Is this OK?

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.
Comment 1 Jeff Hammel 2012-07-18 12:54:03 PDT
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.
Comment 2 Gregory Szorc [:gps] 2012-07-18 13:01:14 PDT
(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.
Comment 3 Gregory Szorc [:gps] 2012-07-24 13:41:54 PDT
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 4 Brendan Eich [:brendan] 2012-07-24 13:42:19 PDT
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
Comment 5 Gregory Szorc [:gps] 2012-07-24 14:03:13 PDT
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.
Comment 6 Ed Morley [:emorley] 2012-07-25 08:11:12 PDT
https://hg.mozilla.org/mozilla-central/rev/21f18a7f5f9d

Note You need to log in before you can comment on or make changes to this bug.