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
syt wrote:
> Another point: I don't like .pth, .pkg files. Isn't this pep an opportunity
> to at least unify them?
Can you propose a unification? I'm concerned that if I propose one,
you may still not like it.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
> I've maybe missed some point, but doesn't the PEP requires
> coordination so that *.pkg files have different names in each portion,
> and the same if one want to provide a non empty __init__.py.
To some degree, coordination is necessary. However, the PEP recommends
that you use .pkg as the name;
On Apr 14, 6:27 pm, "P.J. Eby" wrote:
> I think you've misunderstood something about the use case. System
> packaging tools don't like separate packages to contain the *same
> file*. That means that they *can't* split a larger package up with
> your proposal, because every one of those packages
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
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
Neal Becker wrote:
> While solving this problem, is it possible also to address an issue that
> shows up in certain distributions? I'm specifically talking about the fact
> that on Redhat/Fedora, we have on x86_64 both /usr/lib/pythonxx/ and
> /usr/lib64/pythonxx. The former is supposed to be
> -0
>
> My main concern is that we'll start seeing all kinds of packages with
> names like:
>
> com.dusinc.sarray.ptookkit.v_1_34_beta.btree.BTree
>
> The current lack of global package namespace effectively prevents
> bureaucratic package naming, which in my mind makes it worth the
> cost. Ho
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
While solving this problem, is it possible also to address an issue that
shows up in certain distributions? I'm specifically talking about the fact
that on Redhat/Fedora, we have on x86_64 both /usr/lib/pythonxx/ and
/usr/lib64/pythonxx. The former is supposed to be for non-arch specific
pack
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
"drobi...@gmail.com" writes:
> On Apr 2, 5:59 pm, Ben Finney wrote:
> > Thanks for your constructive criticism, and your considerate quote
> > trimming.
> Ben, you should use google groups.
No, I really shouldn't.
> No trimming necessary.
It's not me that should do the trimming.
http://en.wi
On Apr 2, 5:59 pm, Ben Finney wrote:
> Kay Schluehr writes:
> > Wow. You python-dev guys are really jumping the shark. Isn't your
> > Rube Goldberg "import machinery" already complex enough for you?
>
> Thanks for your constructive criticism, and your considerate quote
> trimming.
Ben, you shoul
Kay Schluehr writes:
> Wow. You python-dev guys are really jumping the shark. Isn't your
> Rube Goldberg "import machinery" already complex enough for you?
Thanks for your constructive criticism, and your considerate quote
trimming.
--
\ “I was married by a judge. I should have asked
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
andrew cooke 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, ...
andrew cooke wrote:
I now want to distribute large optional chunks separately, but ideally
so that the following will will work:
from mortar.rbd import ...
from mortar.zodb import ...
from mortar.wsgi import ...
i may be misunderstanding, but i think you can already do this.
in lepl i have c
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 distribute la
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
On Thu, Apr 2, 2009 at 11:38 AM, Carl Banks wrote:
> On Apr 2, 8:32 am, "Martin v. Löwis" wrote:
>> 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 Pytho
On 2 Apr., 17:32, "Martin v. Löwis" wrote:
> 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 Pytho
On Apr 2, 8:32 am, "Martin v. Löwis" wrote:
> 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 Pyth
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
57 matches
Mail list logo
