[Import-SIG] Is ".ns" really the right extension?
Eric Snow
ericsnowcurrently at gmail.com
Sun Jul 10 00:58:14 CEST 2011
On Sat, Jul 9, 2011 at 3:20 PM, P.J. Eby <pje at telecommunity.com> wrote:
> Looking over the example code I added to the PEP draft (based on Barry's
> suggestion), it occurs to me that, like his example, mine is still
> confusing.
>
> And, now that I look more closely at it, I see that the confusion in large
> part comes from the idea of naming something "ThisPart.ns" -- it implies
> that "ThisPart" is the namespace!
>
> And it's not a namespace at all. It's really a portion of the namespace.
>
> It seems to me that what the actual meaning of a foo.ns file is, "The 'foo'
> portion of the this namespace is installed here". And that thus,
> foo.portion or foo.part or foo.contribution something like that would be
> more appropriate, given the PEP terminology.
>
> I think that a change is needed here to make the PEP's narrative come
> together more cleanly. I'm leaning towards calling them foo.contrib files,
> as in "The 'foo' distribution contributed to this portion of the enclosing
> package."
>
> (Among other things, this makes the need for repeated files clearer; i.e.,
> you add a contribution marker to each package directory you're putting files
> or subdirectories into.)
>
> Overall, the narrative can then lose the constant references to *.ns files
> and instead talk about contribution markers -- i.e. a namespace package
> portion is a directory containing one or more contribution markers. I think
> this will be clearer than the current text, and in particular it should make
> the example directory layout more meaningful to read.
>
> Notice, too, that Eric Snow's confusion about how .ns files work seems to
> have been influenced by the terminology -- i.e., the expectation that a
> 'zope.ns' file was talking about a 'zope' namespace package and identifying
> the containing directory as part of the namespace, rather than the other way
> around. Was that the case, Eric? And if so, do you think that these
> layouts are any clearer?
>
Yeah, that is spot on. I definitely had it backwards. Those examples
make _much_ more sense now, particularly because of the different
extension, and partly from your and Nick's explanations.
>
> ProxyTypes-0.9.tgz:
> peak/
> ProxyTypes.contrib <- marks this as a namespace package portion
> util/
> ProxyTypes.contrib <- same for 'peak.util'
> proxies.py
>
> Importing-1.10.tgz:
> peak/
> Importing.contrib <- marks this as a namespace package portion
> util/
> Importing.contrib <- same for 'peak.util'
> imports.py
>
>
> site-packages/ (or wherever)
> peak/
> Importing.contrib
> ProxyTypes.contrib <- both distributions' contributions are
> merged
> util/
> Importing.contrib <- at both levels
> ProxyTypes.contrib
> imports.py
> proxies.py
>
> Any other thoughts?
>
If two contributions are added into the same directory (a la that last
example) is there a way of telling programatically what portions came
from which contribution?
Also, if two contributions are made to a namespace package on the same
sys.path entry, they must go into the same directory, right? Is there
a way around that, like using zip files or something (might we find
all three above examples in site-packages)? The idea of having them
in separate plain directories (without __init__.py) for the same
sys.path entry is part of what motivated my earlier confusion.
Finally, say a portion is "contributed" to an existing non-namespace
package [directory], turning it into a namespace package. The package
is then impacted by PEP 382 (particularly regarding __init__.py) when
it may not have been developed for use as a namespace package. Is
this case worth considering?
-eric
> _______________________________________________
> Import-SIG mailing list
> Import-SIG at python.org
> http://mail.python.org/mailman/listinfo/import-sig
>
More information about the Import-SIG
mailing list