[Import-SIG] What if namespace imports weren't special?
pje at telecommunity.com
Tue Jul 12 17:34:49 CEST 2011
At 10:58 PM 7/12/2011 +1000, Nick Coghlan wrote:
>For the reasons you say - empty directories aren't handled well by
>many tools and if the directory is going to have content, then
>*somebody* has to define the rules for playing well with others, so it
>may as well be us.
>However, I wrote this before reading PJE's last piece about virtual
>packages. If that idea pans out (and I personally haven't spotted any
>problems with it as yet) then we won't need a marker system at all, so
>the point will become moot.
True enough, but for the record, I like the idea. I had previously
thought of using a marker directory, but discarded it due to the fact
that it seemed to make things more complicated to set up a
package. However, it occurs to me now that packaging tools can take
responsibility for adding marker files to the directory, so for the
end user, you just 'mkdir -p mypkg/py-pkg' or some such. (I'm not
keen on __package__ as the name; I'd rather something
non-importable. But that's a bikeshed for another time.)
I think one other thing that we can and should do with whatever
approach we end up with, is to only require one level of
marker. There's virtually no benefit to restricting subpackage
partitioning, because a subpackage's __path__ is always a subset of
its parent's __path__. So, as soon as you get down to something that
only lives in a single directory, it'll be the same as if you'd
restricted it. Therefore, any drafts we do from this point forward
should only require top-level markers.
More information about the Import-SIG