On 21 Apr 2015, at 7:01 pm, Piotr Ożarowski 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
>>from dwarf import lo
[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
> from dwarf import log # pylint: disable=W0611
> ImportError: No module named dw
Hi Tianon. Thanks for the reply.
On 21 Apr 2015, at 2:41 pm, Tianon Gravi wrote:
>
> On 20 April 2015 at 20:21, Potter, Tim (Cloud Services)
> 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 PYTHO
On 20 April 2015 at 20:21, Potter, Tim (Cloud Services)
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 "/usr/bin/dwarf", line 32, i
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 PYTHONP
On 22 December 2012 22:00, Bas Wijnen 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 with it:
http
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 t
On 22 December 2012 23:27, 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 you mean
> s
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, b
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 mean
something else?
Cheers,
-Barry
signature.asc
Description
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
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/share/. This makes sense, being private data of the packa
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
nt of view, which
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 perso
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
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 p
[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
h 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 though, but in a private directory. All right, I
> just
> have to patch the scripts to add that
Hi Magnus (2011.04.25_21:17:11_+0200)
> dh_python2 will, unless told otherwise, and if modules are installed in the
> standard location, create symlinks in the module trees of all supported
> Python
> versions
Yes, that's how we prefer Python modules to be installed. Usable in
all supported ver
otherwise, 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 standar
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 marke
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
> setuptools.
This is a laudable goal, but not
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 se
Bernd, please follow the Debian mailing list code of conduct
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 material.
>
> I'm confused, then. How does this fit with the implication (in the
> above quoted teset) that upstream should have "thought of [changing
> the location of the modules]"? If downstream hackery is required, I
> don't see what upstream is expected to have done.
>
>
That is imho nothing ups
(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
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, befo
> 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.)
>
> http://cheeseshop.python.org/pypi/gracie/>
The first thing I'd d
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 *doe
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
t 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
> agree with the policy that
> 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
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 p
> 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'
hipped
> in /usr/lib/python2.X/site-packages.
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.
The trouble is, these are modul
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/li
Howdy all,
The Debian Python Policy, chapter 3
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
43 matches
Mail list logo
