On Jun 14, 2011, at 12:02 AM, Piotr Ożarowski wrote:
>it is fine and it is useful... as a submodule, not as a top-level module
Agreed! I think I get what you're driving at now. Some applications don't
put their Python code or tests in a package. In those cases, yes by all means
a private packa
[Barry Warsaw, 2011-06-13]
> it's
> fine to include things like a `test` (Python) subpackage in the (Debian)
> package python-foo. It aligns with the Python "consenting adults" motto, and
> I think such things *can* be useful. As long as the top-level package name is
> unique, subpackage can't po
As an aside, I notice that Debian Python Policy begins by assuming people know
what "private Python modules" are, but this will not be the case for most
Python developers unfamiliar with Debian conventions. Section 2.1 briefly
mentions the distinction from a sys.path-visibility point of view, whic
On Fri, 10 Jun 2011 21:52:11 +0200 Piotr Ożarowski wrote:
>
> install foo to /usr/share/foo/ under a different name, see
> http://lists.debian.org/debian-python/2009/03/msg00091.html
>
Renaming is a great and simple idea, I'll do that.
Thanks to all of you for the quick help,
Eike
pgpG23izp
[Barry Warsaw, 2011-06-10]
> Ah, yeah. Y'know, I am personally not a fan of private modules anyway :).
/me waits till Barry will try to package his 13th package with
Python application that uses "lib" or "tests" module names...
(or will he break after 4th? Bets anyone? ;)
> Note too in a setupto
On Jun 10, 2011, at 09:48 PM, Eike Nicklas wrote:
>Then 'import foo' fails if '/usr/share/foo/foo' is not explicitly added
>to pythonpath (that was the idea of having the module private
>in the first place ;-) )
Ah, yeah. Y'know, I am personally not a fan of private modules anyway :).
Note too i
[Eike Nicklas, 2011-06-10]
> I just tried to package an application using a private module. In this
> case, the name of the script starting the application and the module
> have the same name.
>
> So if the module is in /usr/share/foo/foo, then the script can not
> be /usr/share/foo/foo as well an
Hi Barry,
thanks for the quick answer.
On Fri, 10 Jun 2011 15:34:19 -0400 Barry Warsaw wrote:
> On Jun 10, 2011, at 09:01 PM, Eike Nicklas wrote:
>
> >I just tried to package an application using a private module. In
> >this case, the name of the script starting the application and the
> >modul
2011/6/10 Barry Warsaw :
> Is the script private too? Wouldn't that be better installed in /usr/bin/foo?
>From the 1st alternative he proposes («patch the upstream script to
add /usr/share/foo to pythonpath if
'import foo' fails), I guess he is installing the script into
/usr/share together with
On Jun 10, 2011, at 09:01 PM, Eike Nicklas wrote:
>I just tried to package an application using a private module. In this
>case, the name of the script starting the application and the module
>have the same name.
Is the script private too? Wouldn't that be better installed in /usr/bin/foo?
-Bar
Hi all,
I just tried to package an application using a private module. In this
case, the name of the script starting the application and the module
have the same name.
So if the module is in /usr/share/foo/foo, then the script can not
be /usr/share/foo/foo as well and installing the script
to /us
11 matches
Mail list logo
