On Dec 24, 2012, at 12:43 AM, Dmitrijs Ledkovs wrote:
The way I interpreted Paul's comment is that it implies don't use
virtualenv inside the .deb package as to be distributed by Debian
e.g. system-wide python packages should not be using virtualenv
environment out of the box on Debian, as that
On 22 December 2012 22:00, Bas Wijnen wij...@debian.org wrote:
6. Make /usr/bin/program a symlink to the actual file in the private
directory. It will then search in its real place. (I've seen this used
by angrydd.)
This (symlinking /usr/bin/program) appears to be the recommended way to
deal
On Sat, Dec 22, 2012 at 04:27:46PM -0500, Barry Warsaw wrote:
On Dec 22, 2012, at 05:19 PM, Paul Tagliamonte wrote:
Yeah, please don't use virtualenv, as much as I'd like to see a good way
of using virtualenv in Debian.
Can you expand on that? It should be usable to develop code, but do
On 22 December 2012 23:27, Barry Warsaw ba...@python.org wrote:
On Dec 22, 2012, at 05:19 PM, Paul Tagliamonte wrote:
Yeah, please don't use virtualenv, as much as I'd like to see a good way
of using virtualenv in Debian.
Can you expand on that? It should be usable to develop code, but do you
On Sat, Dec 22, 2012 at 11:00:35PM +0100, Bas Wijnen wrote:
Hello,
I have a Python program (of which I am upstream) and I want to package
it. However, it has some private modules and I don't know how to treat them.
Section 3.1.1 of the Python Packaging Policy says they should be in
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
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, which
[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 pollute
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?
-Barry
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
module have
[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 and
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 in
[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
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
14 matches
Mail list logo
