Not sure if this is the right component, but I'm requesting that the Python package 'blessings' (http://pypi.python.org/pypi/blessings/1.3) 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
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. Gerv
Created attachment 623745 [details] [diff] [review] Add blessings 1.3 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.
Brendan signs off on new top-level directory additions. Gerv
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.
Created attachment 623888 [details] [diff] [review] Add blessings 1.3 as a package 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).
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 https://tbpl.mozilla.org/?tree=Try&rev=b31d597f3a0e 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.
Turns out it really was something with this patch. Changing the virtualenv install order fixed things, interestingly. Try build at https://tbpl.mozilla.org/?tree=Try&rev=4ce135abbf76 proves it. So, I landed in inbound. https://hg.mozilla.org/integration/mozilla-inbound/rev/e03a1f27ce24 https://hg.mozilla.org/integration/mozilla-inbound/rev/9abc60f44fd5
Backed out: https://hg.mozilla.org/mozilla-central/rev/f9d66e743b93 https://hg.mozilla.org/mozilla-central/rev/75312a3da3a6 Please include the bug number in the backout commit message. Thanks!