Jeroen Ruigrok van der Werven wrote:
> -On [20090509 16:07], Chris Withers (ch...@simplistix.co.uk) wrote:
>> They're also all pure namespace packages rather than base + addons,
>> which is what we've been discussing...
>
> But from Martin's email I understood it more as being base packages. Unle
-On [20090509 16:07], Chris Withers (ch...@simplistix.co.uk) wrote:
>They're also all pure namespace packages rather than base + addons,
>which is what we've been discussing...
But from Martin's email I understood it more as being base packages. Unless
I misunderstood, of course.
If correct, whi
Jeroen Ruigrok van der Werven wrote:
-On [20090509 13:40], "Martin v. Löwis" (mar...@v.loewis.de) wrote:
There are a few others, though: zope.*, repoze.*, redturtle.*, iw.*,
plone.*, pycopia.*, p4a.*, plonehrm.*, plonetheme.*, pbp.*, lovely.*,
xm.*, paste.*, Products.*, buildout.*, five.*, silva
-On [20090509 13:40], "Martin v. Löwis" (mar...@v.loewis.de) wrote:
>There are a few others, though: zope.*, repoze.*, redturtle.*, iw.*,
>plone.*, pycopia.*, p4a.*, plonehrm.*, plonetheme.*, pbp.*, lovely.*,
>xm.*, paste.*, Products.*, buildout.*, five.*, silva.*, tl.*, tw.*,
>themerubber.*, them
>> Right: if all portions install into the same directory, you can have
>> base packages already.
>
> Speaking as a user of packages, this use case is one I hardly ever encounter
> with the Python software/modules/packages I use. The only ones that spring
> to mind are the mx.* and ll.* packages.
-On [20090501 20:59], "Martin v. Löwis" (mar...@v.loewis.de) wrote:
>Right: if all portions install into the same directory, you can have
>base packages already.
Speaking as a user of packages, this use case is one I hardly ever encounter
with the Python software/modules/packages I use. The only o
Martin v. Löwis wrote:
I, for one, have been trying to figure out how to do "base namespace"
packages for years...
You mean, without PEP 382?
That won't be possible, unless you can coordinate all addon packages.
Base packages are a feature solely of PEP 382.
Marc-Andre has achieved this, I t
P.J. Eby wrote:
I didn't say there's *no* desire, however IIRC the only person who
*ever* asked on distutils-sig how to do a base package with setuptools
was the author of the ll.* packages.
I've asked before ;-)
Chris
--
Simplistix - Content Management, Zope & Python Consulting
> Actually, if you are using only the distutils, you can do this by
> listing only modules in the addon projects; this is how the ll.* tools
> are doing it. That only works if the packages are all being installed
> in the same directory, though, not as eggs.
Right: if all portions install into th
At 07:41 PM 5/1/2009 +0200, Martin v. Löwis wrote:
>> It's unclear, however, who is using base packages besides mx.* and
>> ll.*, although I'd guess from the PyPI listings that perhaps Django
>> is. (It seems that "base" packages are more likely to use a
>> 'base-extension' naming pattern, vs. t
At 05:35 PM 5/1/2009 +0100, Chris Withers wrote:
P.J. Eby wrote:
It's unclear, however, who is using base packages besides mx.* and
ll.*, although I'd guess from the PyPI listings that perhaps Django
is. (It seems that "base" packages are more likely to use a
'base-extension' naming pattern,
>> It's unclear, however, who is using base packages besides mx.* and
>> ll.*, although I'd guess from the PyPI listings that perhaps Django
>> is. (It seems that "base" packages are more likely to use a
>> 'base-extension' naming pattern, vs. the 'namespace.project' pattern
>> used by "pure" pack
P.J. Eby wrote:
It's unclear, however, who is using base packages besides mx.* and ll.*,
although I'd guess from the PyPI listings that perhaps Django is. (It
seems that "base" packages are more likely to use a 'base-extension'
naming pattern, vs. the 'namespace.project' pattern used by "pure"
P.J. Eby wrote:
At 06:15 PM 4/15/2009 +0200, M.-A. Lemburg wrote:
The much more common use case is that of wanting to have a base package
installation which optional add-ons that live in the same logical
package namespace.
Please see the large number of Zope and PEAK distributions on PyPI as
On 04:56 am, p...@telecommunity.com wrote:
At 03:58 AM 4/17/2009 +, gl...@divmod.com wrote:
Just as a use-case: would the Java "com.*" namespace be an example of
a "pure package with no base"? i.e. lots of projects are in it, but
no project owns it?
Er, I suppose. I was thinking more of
At 03:58 AM 4/17/2009 +, gl...@divmod.com wrote:
Just as a use-case: would the Java "com.*" namespace be an example
of a "pure package with no base"? i.e. lots of projects are in it,
but no project owns it?
Er, I suppose. I was thinking more of the various 'com.foo' and
'org.bar' packag
On 16 Apr, 03:36 pm, p...@telecommunity.com wrote:
At 03:46 AM 4/16/2009 +, gl...@divmod.com wrote:
On 15 Apr, 09:11 pm, p...@telecommunity.com wrote:
Twisted has its own system for "namespace" packages, and I'm not
really sure where we fall in this discussion. I haven't been able to
fo
At 03:46 AM 4/16/2009 +, gl...@divmod.com wrote:
On 15 Apr, 09:11 pm, p...@telecommunity.com wrote:
I think that there is some confusion here. A "main" package or
buildout that assembles a larger project from components is not the
same thing as having a "base" package for a namespace pack
On 15 Apr, 09:11 pm, p...@telecommunity.com wrote:
I think that there is some confusion here. A "main" package or
buildout that assembles a larger project from components is not the
same thing as having a "base" package for a namespace package.
I'm certainly confused.
Twisted has its own sy
At 09:59 AM 4/16/2009 +0900, Stephen J. Turnbull wrote:
I think that for this PEP it's more important to unify
the various use cases for namespace packages than it is to get rid of
the .pth files.
Actually, Martin's proposal *does* get rid of the .pth files in
site-packages, and replaces them
M.-A. Lemburg writes:
> Hmm, setuptools doesn't support the notion of base packages, ie.
> packages that provide their own __init__.py module, so I fail
> to see how your list or any other list of setuptools-depend
> packages can be taken as indicator for anything related to
> base packages.
At 10:00 PM 4/15/2009 +0200, Tarek Ziadé wrote:
Now for the "base" or "core" package, what peoplethat uses setuptools
do most of the time:
1- they use zc.buildout so they don't need a base package : they list
in a configuration files all packages needed
to build the application, and one of th
At 10:20 PM 4/15/2009 +0200, M.-A. Lemburg wrote:
Whether base packages are useful or not is really a side aspect
of the PEP and my proposal.
It's not whether they're useful, it's whether they're required. Your
proposal *requires* base packages, and for people who intend to use
pure packages
On 2009-04-15 21:22, P.J. Eby wrote:
> At 02:52 PM 4/15/2009 -0400, A.M. Kuchling wrote:
>> On Wed, Apr 15, 2009 at 01:59:34PM -0400, P.J. Eby wrote:
>> > Please see the large number of Zope and PEAK distributions on PyPI as
>> > minimal examples that disprove this being the common use case. I
>>
On Wed, Apr 15, 2009 at 9:22 PM, P.J. Eby wrote:
> At 02:52 PM 4/15/2009 -0400, A.M. Kuchling wrote:
>>
>> On Wed, Apr 15, 2009 at 01:59:34PM -0400, P.J. Eby wrote:
>> > Please see the large number of Zope and PEAK distributions on PyPI as
>> > minimal examples that disprove this being the common
At 02:52 PM 4/15/2009 -0400, A.M. Kuchling wrote:
On Wed, Apr 15, 2009 at 01:59:34PM -0400, P.J. Eby wrote:
> Please see the large number of Zope and PEAK distributions on PyPI as
> minimal examples that disprove this being the common use case. I expect
> you will find a fair number of others, a
On Wed, Apr 15, 2009 at 01:59:34PM -0400, P.J. Eby wrote:
> Please see the large number of Zope and PEAK distributions on PyPI as
> minimal examples that disprove this being the common use case. I expect
> you will find a fair number of others, as well.
...
> In other words, the "base packag
On 2009-04-15 19:59, P.J. Eby wrote:
> At 06:15 PM 4/15/2009 +0200, M.-A. Lemburg wrote:
>> The much more common use case is that of wanting to have a base package
>> installation which optional add-ons that live in the same logical
>> package namespace.
>
> Please see the large number of Zope and
On Apr 15, 2009, at 12:15 PM, M.-A. Lemburg wrote:
The much more common use case is that of wanting to have a base
package
installation which optional add-ons that live in the same logical
package namespace.
The PEP provides a way to solve this use case by giving both
developers
and users
On 2009-04-15 19:38, James Y Knight wrote:
>
> On Apr 15, 2009, at 12:15 PM, M.-A. Lemburg wrote:
>
>> The much more common use case is that of wanting to have a base package
>> installation which optional add-ons that live in the same logical
>> package namespace.
>>
>> The PEP provides a way to
At 06:15 PM 4/15/2009 +0200, M.-A. Lemburg wrote:
The much more common use case is that of wanting to have a base package
installation which optional add-ons that live in the same logical
package namespace.
Please see the large number of Zope and PEAK distributions on PyPI as
minimal examples
At 09:10 AM 4/15/2009 -0700, Aahz wrote:
For the benefit of us bystanders, could you summarize your vote at this
point? Given the PEP's intended goals, if you do not oppose the PEP, are
there any changes you think should be made?
I'm +1 on Martin's original version of the PEP, subject to the p
On 2009-04-15 16:44, P.J. Eby wrote:
> At 09:51 AM 4/15/2009 +0200, M.-A. Lemburg wrote:
>> On 2009-04-15 02:32, P.J. Eby wrote:
>> > At 10:59 PM 4/14/2009 +0200, M.-A. Lemburg wrote:
>> >> You are missing the point: When breaking up a large package that
>> lives in
>> >> site-packages into smaller
[much quote-trimming, the following is intended to just give the gist,
but the bits quoted below are not in directe response to each other]
On Wed, Apr 15, 2009, P.J. Eby wrote:
> At 09:51 AM 4/15/2009 +0200, M.-A. Lemburg wrote:
>>
>> [...]
>> Again: the PEP is about creating a standard for nam
At 09:51 AM 4/15/2009 +0200, M.-A. Lemburg wrote:
On 2009-04-15 02:32, P.J. Eby wrote:
> At 10:59 PM 4/14/2009 +0200, M.-A. Lemburg wrote:
>> You are missing the point: When breaking up a large package that lives in
>> site-packages into smaller distribution bundles, you don't need namespace
>> p
On 2009-04-15 02:32, P.J. Eby wrote:
> At 10:59 PM 4/14/2009 +0200, M.-A. Lemburg wrote:
>> You are missing the point: When breaking up a large package that lives in
>> site-packages into smaller distribution bundles, you don't need namespace
>> packages at all, so the PEP doesn't apply.
>>
>> The
At 10:59 PM 4/14/2009 +0200, M.-A. Lemburg wrote:
You are missing the point: When breaking up a large package that lives in
site-packages into smaller distribution bundles, you don't need namespace
packages at all, so the PEP doesn't apply.
The way this works is by having a base distribution bun
On 2009-04-14 18:27, P.J. Eby wrote:
> At 05:02 PM 4/14/2009 +0200, M.-A. Lemburg wrote:
>> I don't see the emphasis in the PEP on Linux distribution support and the
>> remote possibility of them wanting to combine separate packages back
>> into one package as good argument for adding yet another s
At 05:02 PM 4/14/2009 +0200, M.-A. Lemburg wrote:
I don't see the emphasis in the PEP on Linux distribution support and the
remote possibility of them wanting to combine separate packages back
into one package as good argument for adding yet another separate hierarchy
of special files which Pytho
On 2009-04-07 19:46, P.J. Eby wrote:
> At 04:58 PM 4/7/2009 +0200, M.-A. Lemburg wrote:
>> On 2009-04-07 16:05, P.J. Eby wrote:
>> > At 02:30 PM 4/7/2009 +0200, M.-A. Lemburg wrote:
>> >> >> Wouldn't it be better to stick with a simpler approach and look for
>> >> >> "__pkg__.py" files to detect na
At 04:58 PM 4/7/2009 +0200, M.-A. Lemburg wrote:
On 2009-04-07 16:05, P.J. Eby wrote:
> At 02:30 PM 4/7/2009 +0200, M.-A. Lemburg wrote:
>> >> Wouldn't it be better to stick with a simpler approach and look for
>> >> "__pkg__.py" files to detect namespace packages using that O(1)
>> check ?
>> >
On Tue, Apr 7, 2009 at 11:58 PM, M.-A. Lemburg wrote:
>>
>> This means your proposal actually doesn't add any benefit over the
>> status quo, where you can have an __init__.py that does nothing but
>> declare the package a namespace. We already have that now, and it
>> doesn't need a new filenam
On 2009-04-07 16:05, P.J. Eby wrote:
> At 02:30 PM 4/7/2009 +0200, M.-A. Lemburg wrote:
>> >> Wouldn't it be better to stick with a simpler approach and look for
>> >> "__pkg__.py" files to detect namespace packages using that O(1)
>> check ?
>> >
>> > Again - this wouldn't be O(1). More importantl
At 02:30 PM 4/7/2009 +0200, M.-A. Lemburg wrote:
>> Wouldn't it be better to stick with a simpler approach and look for
>> "__pkg__.py" files to detect namespace packages using that O(1) check ?
>
> Again - this wouldn't be O(1). More importantly, it breaks system
> packages, which now again have
[Resent due to a python.org mail server problem]
On 2009-04-03 22:07, Martin v. Löwis wrote:
>> I'd like to extend the proposal to Python 2.7 and later.
>
> I don't object, but I also don't want to propose this, so
> I added it to the discussion.
>
> My (and perhaps other people's) concern is th
On 2009-04-03 02:44, P.J. Eby wrote:
> At 10:33 PM 4/2/2009 +0200, M.-A. Lemburg wrote:
>> Alternative Approach:
>> -
>>
>> Wouldn't it be better to stick with a simpler approach and look for
>> "__pkg__.py" files to detect namespace packages using that O(1) check ?
>
>> One of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Noller wrote:
> On Mon, Apr 6, 2009 at 12:28 PM, R. David Murray
> wrote:
>> On Mon, 6 Apr 2009 at 12:00, Jesse Noller wrote:
>>> On Mon, Apr 6, 2009 at 9:26 AM, Barry Warsaw wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Apr 6, 2009 at 12:28 PM, R. David Murray wrote:
> On Mon, 6 Apr 2009 at 12:00, Jesse Noller wrote:
>>
>> On Mon, Apr 6, 2009 at 9:26 AM, Barry Warsaw wrote:
>>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> On Apr 6, 2009, at 9:21 AM, Jesse Noller wrote:
>>>
On Thu, A
On Mon, 6 Apr 2009 at 12:00, Jesse Noller wrote:
On Mon, Apr 6, 2009 at 9:26 AM, Barry Warsaw wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 6, 2009, at 9:21 AM, Jesse Noller wrote:
On Thu, Apr 2, 2009 at 4:33 PM, M.-A. Lemburg wrote:
On 2009-04-02 17:32, Martin v. L?wis wrot
On Mon, Apr 6, 2009 at 9:26 AM, Barry Warsaw wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Apr 6, 2009, at 9:21 AM, Jesse Noller wrote:
>
>> On Thu, Apr 2, 2009 at 4:33 PM, M.-A. Lemburg wrote:
>>>
>>> On 2009-04-02 17:32, Martin v. Löwis wrote:
I propose the following
P.J. Eby wrote:
See the third paragraph of
http://www.python.org/dev/peps/pep-0382/#discussion
Indeed, I guess the PEP could be made more explanatory then 'cos, as a
packager, I don't see what I'd put in the various setup.py and
__init__.py to make this work...
That said, I'm delighted to
At 02:00 PM 4/6/2009 +0100, Chris Withers wrote:
Martin v. Löwis wrote:
Chris Withers wrote:
Would this support the following case:
I have a package called mortar, which defines useful stuff:
from mortar import content, ...
I now want to distribute large optional chunks separately, but ideal
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Apr 6, 2009, at 9:21 AM, Jesse Noller wrote:
>
>> On Thu, Apr 2, 2009 at 4:33 PM, M.-A. Lemburg wrote:
>>> On 2009-04-02 17:32, Martin v. Löwis wrote:
I propose the following PEP for inclusion to Python 3.1.
>>>
>>> Thanks for picking t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 6, 2009, at 9:21 AM, Jesse Noller wrote:
On Thu, Apr 2, 2009 at 4:33 PM, M.-A. Lemburg wrote:
On 2009-04-02 17:32, Martin v. Löwis wrote:
I propose the following PEP for inclusion to Python 3.1.
Thanks for picking this up.
I'd like to e
On Thu, Apr 2, 2009 at 4:33 PM, M.-A. Lemburg wrote:
> On 2009-04-02 17:32, Martin v. Löwis wrote:
>> I propose the following PEP for inclusion to Python 3.1.
>
> Thanks for picking this up.
>
> I'd like to extend the proposal to Python 2.7 and later.
>
-1 to adding it to the 2.x series. There wa
Martin v. Löwis wrote:
Chris Withers wrote:
Martin v. Löwis wrote:
I propose the following PEP for inclusion to Python 3.1.
Please comment.
Would this support the following case:
I have a package called mortar, which defines useful stuff:
from mortar import content, ...
I now want to dist
On Fri, Apr 3, 2009 at 13:15, "Martin v. Löwis" wrote:
> > Note that there is no such thing as a "defining namespace package" --
> > namespace package contents are symmetrical peers.
>
> With the PEP, a "defining package" becomes possible - at most one
> portion can define an __init__.py.
>
> I k
At 10:15 PM 4/3/2009 +0200, Martin v. Löwis wrote:
I should make it clear that this is not the case. I envision it to work
this way: import zope
- searches sys.path, until finding either a directory zope, or a file
zope.{py,pyc,pyd,...}
- if it is a directory, it checks for .pkg files. If it fi
On 08:15 pm, mar...@v.loewis.de wrote:
Note that there is no such thing as a "defining namespace package" --
namespace package contents are symmetrical peers.
With the PEP, a "defining package" becomes possible - at most one
portion can define an __init__.py.
For what it's worth, this is a _s
> Note that there is no such thing as a "defining namespace package" --
> namespace package contents are symmetrical peers.
With the PEP, a "defining package" becomes possible - at most one
portion can define an __init__.py.
I know that the current mechanisms don't support it, and it might
not be
> I'd like to extend the proposal to Python 2.7 and later.
I don't object, but I also don't want to propose this, so
I added it to the discussion.
My (and perhaps other people's) concern is that 2.7 might
well be the last release of the 2.x series. If so, adding
this feature to it would make 2.7
Chris Withers wrote:
> Martin v. Löwis wrote:
>> I propose the following PEP for inclusion to Python 3.1.
>> Please comment.
>
> Would this support the following case:
>
> I have a package called mortar, which defines useful stuff:
>
> from mortar import content, ...
>
> I now want to distribut
> Perhaps we could add something like a sys.namespace_packages that would
> be updated by this mechanism? Then, pkg_resources could check both that
> and its internal registry to be both backward and forward compatible.
I could see no problem with that, so I have added this to the PEP.
Thanks fo
At 03:21 AM 4/3/2009 +0200, Matthias Klose wrote:
+1 speaking as a downstream packaging python for Debian/Ubuntu I
welcome this approach. The current practice of shipping the very
same file (__init__.py) in different packages leads to conflicts for
the installation of these packages (this is n
Martin v. Löwis schrieb:
> I propose the following PEP for inclusion to Python 3.1.
> Please comment.
>
> Regards,
> Martin
>
> Abstract
>
>
> Namespace packages are a mechanism for splitting a single Python
> package across multiple directories on disk. In current Python
> versions, an
At 10:33 PM 4/2/2009 +0200, M.-A. Lemburg wrote:
That's going to slow down Python package detection a lot - you'd
replace an O(1) test with an O(n) scan.
I thought about this too, but it's pretty trivial considering that
the only time it takes effect is when you have a directory name that
mat
On 2009-04-02 17:32, Martin v. Löwis wrote:
> I propose the following PEP for inclusion to Python 3.1.
Thanks for picking this up.
I'd like to extend the proposal to Python 2.7 and later.
> Please comment.
>
> Regards,
> Martin
>
> Specification
> =
>
> Rather than using an impera
P.J. Eby wrote:
Apart from that, this mechanism sounds great! I only wish there was a
way to backport it all the way to 2.3 so I could drop the messy bits
from setuptools.
Maybe we could? :-)
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplist
Martin v. Löwis wrote:
I propose the following PEP for inclusion to Python 3.1.
Please comment.
Would this support the following case:
I have a package called mortar, which defines useful stuff:
from mortar import content, ...
I now want to distribute large optional chunks separately, but id
At 10:32 AM 4/2/2009 -0500, Martin v. Löwis wrote:
I propose the following PEP for inclusion to Python 3.1.
Please comment.
An excellent idea. One thing I am not 100% clear on, is how to get
additions to sys.path to work correctly with this. Currently, when
pkg_resources adds a new egg to s
I propose the following PEP for inclusion to Python 3.1.
Please comment.
Regards,
Martin
Abstract
Namespace packages are a mechanism for splitting a single Python
package across multiple directories on disk. In current Python
versions, an algorithm to compute the packages __path__ must
71 matches
Mail list logo
