Hi Tianon. Thanks for the reply.
On 21 Apr 2015, at 2:41 pm, Tianon Gravi admwig...@gmail.com wrote:
On 20 April 2015 at 20:21, Potter, Tim (Cloud Services)
timothy.pot...@hp.com wrote:
It looks pretty good, but I think I have messed up something as my binary
gives an import error since
[Potter, Tim (Cloud Services), 2015-04-21]
binary gives an import error since /usr/share/dwarf isn’t in the PYTHONPATH:
# dwarf
Traceback (most recent call last):
File /usr/bin/dwarf, line 32, in module
from dwarf import log # pylint: disable=W0611
ImportError: No module named
On 21 Apr 2015, at 7:01 pm, Piotr Ożarowski pi...@debian.org wrote:
[Potter, Tim (Cloud Services), 2015-04-21]
binary gives an import error since /usr/share/dwarf isn’t in the PYTHONPATH:
# dwarf
Traceback (most recent call last):
File /usr/bin/dwarf, line 32, in module
from dwarf
Hi everyone. I recently filed in ITP (#782988) and had a stab at packaging the
app based on the instructions at https://wiki.debian.org/Python/Packaging.
It looks pretty good, but I think I have messed up something as my binary gives
an import error since /usr/share/dwarf isn’t in the
On 20 April 2015 at 20:21, Potter, Tim (Cloud Services)
timothy.pot...@hp.com wrote:
It looks pretty good, but I think I have messed up something as my binary
gives an import error since /usr/share/dwarf isn’t in the PYTHONPATH:
# dwarf
Traceback (most recent call last):
File
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
/usr
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
doesn't really explain much. I'd like to see a section early on which defines
private modules, where, when, why and how they should be used, etc.
On Jun 10, 2011, at 10:13 PM, Piotr Ożarowski wrote:
[Barry Warsaw, 2011-06-10]
Ah, yeah. Y'know, I am personally not a fan of private modules
[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
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
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
[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 setuptools
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
, and if modules are installed in the
standard location, create symlinks in the module trees of all supported Python
versions, which is a bit pointless for modules used only by the application in
question. AFAIU the Python policy such private modules should not be installed
in the standard location
Josselin Mouette [EMAIL PROTECTED] writes:
Le jeudi 11 octobre 2007 à 10:50 +1000, Ben Finney a écrit :
The main reason I use distutils is to assist those people using
operating systems that *don't* have good package dependency
management, which seems to be the primary target market for
Bernd, please follow the Debian mailing list code of conduct
URL:http://www.debian.org/MailingLists#codeofconduct, in particular
by *not* sending personal copies of messages that are also sent to the
list.
Also, please preserve attribution lines so we can keep track of who
wrote what quoted
Ben Finney [EMAIL PROTECTED] writes:
The main reason I use distutils is to assist those people using
operating systems that *don't* have good package dependency
management, which seems to be the primary target market for
setuptools.
This should, of course, read The main reason I use
Le lundi 01 octobre 2007 à 23:56 +1000, Ben Finney a écrit :
Hmm. I am hoping that modify the programs [to add an absolute
path to the search path] is not a necessary part of this.
If upstream hasn't thought of it, it is. You only need to add one
line in the program, before the module
(Please preserve attribution lines on quoted material. I don't know
who wrote what in the following.)
Josselin Mouette [EMAIL PROTECTED] writes:
Le lundi 01 octobre 2007 à 23:56 +1000, Ben Finney a écrit :
Hmm. I am hoping that modify the programs [to add an absolute
path to the search
Le lundi 01 octobre 2007 à 14:42 +1000, Ben Finney a écrit :
3.1.1 Programs Shipping Private Modules
A program using /usr/bin/python as interpreter can come up with
private Python modules. These modules should be installed in
/usr/share/module, or /usr/lib/module
them by default,
yes. I don't know what magic is required to put them elsewhere; that
may be part of the answer, if someone can instruct me on how to do it.
The trouble is, these are modules that clearly fall under the private
modules for the program description in the policy document. I fully
That's where the distutils and setuptools place them by default,
yes. I don't know what magic is required to put them elsewhere; that
may be part of the answer, if someone can instruct me on how to do it.
You shoul dupload your work somewhere, teaching you is almost
impossible if one can't
Bernd Zeimetz [EMAIL PROTECTED] writes:
You shoul dupload your work somewhere, teaching you is almost
impossible if one can't see what's wrong.
I'm not presenting something as wrong. I'm asking for guidance on
how to do things right.
If the policy recommends that packages be set up a
If the policy recommends that packages be set up a particular way
(put package-specific modules in '/usr/share/package/'), but the
standard tools behave differently (put all modules by default in
'/usr/lib/pythonX.Y/site-packages/'), then there's a step that needs
to be taken to get from the
of the answer, if someone can instruct me on how to do it.
The trouble is, these are modules that clearly fall under the private
modules for the program description in the policy document. I fully
agree with the policy that modules intended for internal use by a
discrete set of programs should
Josselin Mouette [EMAIL PROTECTED] writes:
Le lundi 01 octobre 2007 à 18:37 +1000, Ben Finney a écrit :
How can I use the tools available — distutils, setuptools,
debhelper — to install these package-specific modules to a
package-specific location, such that all the programs in the
Ben Finney [EMAIL PROTECTED] writes:
How can I best conform to the [Debian policy for Python modules
specific to a single package]?
As an example, here's a Python package I'm trying to get packaged for
Debian. (I am the upstream author of this one, but I'm interested in a
solution that
As an example, here's a Python package I'm trying to get packaged for
Debian. (I am the upstream author of this one, but I'm interested in a
solution that *doesn't* involve significant changes to the upstream
code.)
URL:http://cheeseshop.python.org/pypi/gracie/
The first thing I'd do
Howdy all,
The Debian Python Policy, chapter 3
URL:http://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html
says:
3.1.1 Programs Shipping Private Modules
A program using /usr/bin/python as interpreter can come up with
private Python modules. These modules should
36 matches
Mail list logo
