Closed Bug 754469 Opened 9 years ago Closed 9 years ago

Import blessings Python package into mozilla-central


(Core :: General, defect)

Not set





(Reporter: gps, Assigned: gps)




(2 files)

Not sure if this is the right component, but I'm requesting that the Python package 'blessings' ( be imported into mozilla-central. This package provides high-level terminal control to enable things like color, positioning, etc.

The driving force behind this request is that I want more user-friendly tools in the repository. Pretty terminal interaction is a way of providing more user-friendly tools. One such tool is in the pipes at bug 751795.

I'm not sure if we need to get legal sign-off or what when it comes to importing external code. So, I figured I can get that sign-off first (from Gerv or whomever) and then submit a patch for review.
gps: no problems from a licensing point of view.

Gerv: rock on!

Ted, etc: what's the appropriate location for this? other-licenses/blessings?
That seems fine, there's precedent for that location (virtualenv, simplejson, ply).
NO! Not other-licenses!

Read the README in other-licenses.

Let's kill this strange idea that other-licenses is for non-MPL things. It's for non-MPL-_compatible_ things.

Patch includes the original LICENSE file.

Attempting to sneak in the creation of a new top-level directory, pylib/, as a site-packages like directory for all Python (in a similar vein of bug 661908). In my utopia world, all (MPL-compatible) code would exist in one unified tree and would be easily locatable. Ted: if you don't agree, please tell me where else to put this, as I have no clue.
Assignee: nobody → gps
Attachment #623745 - Flags: review?(ted.mielczarek)
Brendan signs off on new top-level directory additions.

Brendan: 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 location. This would make it easier to find and hack on. It may also lead to better code cohesion and quality.

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/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
If other-licenses is contentious and we don't want a new top-level directory, feel free to stash it in build/pylib or build/python or whatever. I don't really care. Also, you don't really need review from me if you're just landing a Python module there that's NPOTB.
To complicate things even more, we probably need two Python trees: 1 containing packages with all their metadata as downloaded from PyPI and 1 for pure source (like what is in build/ config/ today). The sub-tree containing wholesale packages would need build system integration (like bug 661908).

pylib/package-sources and pyblic/sources?
Fine with me, although I'd probably just say /packages. We were just talking about single-file-module installation into the virtualenv, it seems fairly simple.
(In reply to Ted Mielczarek [:ted] from comment #10)
> Fine with me, although I'd probably just say /packages. We were just talking
> about single-file-module installation into the virtualenv, it seems fairly
> simple.

For some things, yes. I /could/ resubmit this patch containing all of the package metadata files. I stripped what I thought was needless.
Here is the version as a full package (literally uncompressed the tarball from upstream). We would need to hook this up with the build system somehow (likely through bug 661908).
Attachment #623745 - Flags: review?(ted.mielczarek)
I'll just create build/pylib for now. We can always create a new top-level directory at some later date if we ever do consolidate the Python code.

Try at

Per comment #8, I don't think I need a review to land this. So, once Try comes back green, it's landing in inbound.
Backed out because I was stupid and pushed while the OS X builders were still broken.
Target Milestone: mozilla15 → ---
Depends on: 758694
Turns out it really was something with this patch. Changing the virtualenv install order fixed things, interestingly. Try build at proves it.

So, I landed in inbound.
No longer depends on: 758694
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla15
Backed out:

Please include the bug number in the backout commit message.  Thanks!
Resolution: FIXED → ---
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Blocks: 777068
You need to log in before you can comment on or make changes to this bug.