Simon McVittie writes:
> I'd install them with names like this:
>
> /usr/share/openastro.org/openastromod/__init__.py
> /usr/share/openastro.org/openastromod/swiss.py
> (etc.)
>
> and in the application that needs them, add '/usr/share/openastro.org'
> to the sys.path before you "import openastro
Barry Warsaw writes:
> Debian "package-name" or Python "package-name"? :)
When I get a time machine, I won't mess about speaking with Benjamin
Franklin http://xkcd.com/567/>, I will be speaking with Guido van
Rossum and convincing him that the term “package” is already taken and
not available fo
* Brian Sutherland , 2012-04-30, 19:47:
How are you actually running the tests with adt-run. Did you actually
setup a testbed, or is there now an easy way to run the tests?
When you apply the patch from bug #648148, you can use your host system
as testbed. You run this in an unpacked (and buil
On Apr 30, 2012, at 05:13 PM, Simon McVittie wrote:
>I hope you're not arguing that virt-manager, the Gtk tool for managing
>virtual machines, ought to be called python-virtmanager, just because it
>happens to be implemented in Python and contain a private Python package
>(off the default sys.path
On Sat, Apr 21, 2012 at 10:33:24PM +0200, Jakub Wilk wrote:
> 3) Provide one test that is run against all installed versions
> (pyversions -i):
>
> Tests: test-installed
> Depends: python-pet-module
>
> This is a variant of 2 which is more friendly to users who can't or
> don't want t
On 30/04/12 17:29, Paul Elliott wrote:
> I want to move the python package openastromod to a private
> location.
>
> My package, (openastro.org) before modification, when it is still
> creating a public python package, creates: (from dpkg-query -L
> openastro.org)
>
> /usr/share/pyshared/openastr
On Monday, April 30, 2012 03:45:35 AM Piotr Ożarowski wrote:
> [Ben Finney, 2012-04-30]
>
> > Paul Elliott writes:
> > > My package uses a package that it makes public. What is the standard,
> > > established way to take that package private?
> >
> > In the absence of better-informed answers (pl
additional few cents which might come handy if you decide to go that way
1. I would recommend to override matplotlib backend to Agg before
running tests
2. set HOME to build/ (or some other temp directory)
to prevent common problems for those projects which use matplotlib in
some of the tests
On 30/04/12 15:50, Barry Warsaw wrote:
> On Apr 30, 2012, at 12:08 PM, Simon McVittie wrote:
>> I think it would still be clearer to say
>> /usr/share/package-name/module.py, /usr/lib/package-name/module.so,
>> assuming the library-user code involves "import module"?
>
> Debian "package-name" or P
[Barry Warsaw, 2012-04-30]
> >I think it would still be clearer to say
> >/usr/share/package-name/module.py, /usr/lib/package-name/module.so,
> >assuming the library-user code involves "import module"?
>
> Debian "package-name" or Python "package-name"? :)
I use Debian binary package name unless
On Apr 30, 2012, at 11:04 AM, Yaroslav Halchenko wrote:
>With such a massive automated "packaging" it would be great if from day
>0 you would think about adding build-time testing into the
>pipeline. It should be quite easy to discover if module carries any
>unittests (grep for unittest ;) ) and w
On Apr 30, 2012, at 05:00 PM, Piotr Ożarowski wrote:
>I don't remember arguments against making it the default,
>will have to dig the IRC/mailing list archives later.
I'd prefer "rewrite" since I think /usr/bin/env is almost always the wrong
thing to use in production (though I acknowledge Stefan
On Mon, 30 Apr 2012, Natalia Frydrych wrote:
> Please note, that the tool that I intend to write, will be designed to
> convert as many PyPI packages as possible and making them available in
> a deb repository (for the selected version of Debian), and then update
> them when new versions of existi
[Barry Warsaw, 2012-04-30]
> On Apr 30, 2012, at 11:23 AM, Piotr Ożarowski wrote:
>
> >[Barry Warsaw, 2012-04-25]
> >> - dh_python{2,3} should rewrite the shebang lines by default, with an
> >> option
> >>to disable that.
> >
> >there wasn't a consensus so I dropped this idea, I think I will
On Apr 30, 2012, at 12:08 PM, Simon McVittie wrote:
>On 30/04/12 10:39, Piotr Ożarowski wrote:
>> [Piotr Ożarowski, 2012-04-30]
>>> I will change that to /usr/share/package-name/module and
>>> /usr/lib/package-name/module if no one objects
>>> (adding /usr/share or /usr/lib to sys.path is not a go
On Apr 30, 2012, at 11:23 AM, Piotr Ożarowski wrote:
>[Barry Warsaw, 2012-04-25]
>> - dh_python{2,3} should rewrite the shebang lines by default, with an option
>>to disable that.
>
>there wasn't a consensus so I dropped this idea, I think I will add it
>as an optional feature in next upload,
On Apr 30, 2012, at 04:07 PM, Natalia Frydrych wrote:
>2012/4/29 Andrew Straw :
>> (I'm coming at this very late - apologies for only noticing your email now.)
>> What you describe is exactly the pypi-install command of stdeb:
>> http://github.com/astraw/stdeb .
>
>Stdeb is one of the programs tha
2012/4/29 Andrew Straw :
> (I'm coming at this very late - apologies for only noticing your email now.)
> What you describe is exactly the pypi-install command of stdeb:
> http://github.com/astraw/stdeb .
Stdeb is one of the programs that I intend to use. I agreed with my
mentor that in the beginn
Le Thu, Mar 22, 2012 at 08:47:10AM +0900, Charles Plessy a écrit :
> Le Tue, Mar 20, 2012 at 10:57:34AM -0400, Scott Moser a écrit :
> >
> > The grub stuff is only in the ubuntu package, and arguably should be
> > separate source from cloud-init entirely. Basically, it maintains
> > /boot/grub/me
On 30-Apr-12 12:29, Piotr Ożarowski wrote:
[Andrew Straw, 2012-04-29]
(I'm coming at this very late - apologies for only noticing your
email now.) What you describe is exactly the pypi-install command of
stdeb: http://github.com/astraw/stdeb .
this new tool will not replace stdeb, it will exten
On 30/04/12 10:39, Piotr Ożarowski wrote:
> [Piotr Ożarowski, 2012-04-30]
>> I will change that to /usr/share/package-name/module and
>> /usr/lib/package-name/module if no one objects
>> (adding /usr/share or /usr/lib to sys.path is not a good idea, we don't
>> do that so policy should be updated)
On 30/04/12 09:45, Piotr Ożarowski wrote:
> I will change that to /usr/share/package-name/module and
> /usr/lib/package-name/module if no one objects
> (adding /usr/share or /usr/lib to sys.path is not a good idea, we don't
> do that so policy should be updated)
Some PyGTK apps seem to make good e
[Andrew Straw, 2012-04-29]
> (I'm coming at this very late - apologies for only noticing your
> email now.) What you describe is exactly the pypi-install command of
> stdeb: http://github.com/astraw/stdeb .
this new tool will not replace stdeb, it will extend it
(/me pings Natalia to provide more
[BRAGA, Bruno, 2012-04-30]
> > > b) add current installation to python path (eg. /usr/share/program) so
> > the
> > > plugin can import the programlib packages/modules.
> >
> > plugins import programlib at runtime only, riht? Startup script is
> > adding . to the sys.path automaticall so plugins sh
On Mon, Apr 30, 2012 at 7:55 PM, Piotr Ożarowski wrote:
> [BRAGA, Bruno, 2012-04-25]
> > When compiling/building the source with setup.py, I encountered the
> problem
> > that separating the plugin as an independent solution:
> >
> > program/
> > |
> > | setup.py
> > |
> > |--
done by myself as of r21456+r21457.
Please refrain from doing any other such changes on packages I
co-maintain without a previous agreement.
Sandro
On Mon, Apr 30, 2012 at 11:36, Sandro Tosi wrote:
> Sorry but WTF???
>
> Why didn't you contact me about it? changes like new helper, source
> form
[BRAGA, Bruno, 2012-04-25]
> When compiling/building the source with setup.py, I encountered the problem
> that separating the plugin as an independent solution:
>
> program/
> |
> | setup.py
> |
> | plugins/
> | |
> | |--pluginA/
> | |
>
[Piotr Ożarowski, 2012-04-30]
> [Ben Finney, 2012-04-30]
> > Paul Elliott writes:
> >
> > > My package uses a package that it makes public. What is the standard,
> > > established way to take that package private?
> >
> > In the absence of better-informed answers (please, knowledgeable Debian
>
Sorry but WTF???
Why didn't you contact me about it? changes like new helper, source
format, request an ack from the real-person behind the package, that's
me. Please revert them right now.
On Mon, Apr 30, 2012 at 01:30, wrote:
> Date: Sunday, April 29, 2012 @ 23:30:30
> Author: jandd
> Rev
[BRAGA, Bruno, 2012-04-30]
> No need to mess with setup.py directly. Use dh_python2 to do the packaging
> work for you, and rely on debian/rules to define the location of your
> files. Read:
FTR: dh_python2 doesn't invoke setup.py, dh (the sequencer) does
--
Piotr Ożarowski
[Barry Warsaw, 2012-04-25]
> - dh_python{2,3} should rewrite the shebang lines by default, with an option
>to disable that.
there wasn't a consensus so I dropped this idea, I think I will add it
as an optional feature in next upload, though.
--
Piotr Ożarowski Debian
[Ben Finney, 2012-04-30]
> Paul Elliott writes:
>
> > My package uses a package that it makes public. What is the standard,
> > established way to take that package private?
>
> In the absence of better-informed answers (please, knowledgeable Debian
> Python people, help us out with this inform
* Ben Finney , 2012-04-30, 14:09:
That said, there doesn't appear to be much easily-found documentation on
how to do that with the available tools. The best I can find is:
Add these three lines [to ‘debian/rules’]:
override_dh_auto_install:
python setup.py install --root=debi
[Jakub Wilk, 2012-04-30]
> * BRAGA, Bruno , 2012-04-30, 10:03:
> >No need to mess with setup.py directly. Use dh_python2 to do the
> >packaging work for you, and rely on debian/rules to define the
> >location of your files. Read:
> >http://wiki.debian.org/Python/TransitionToDHPython2
>
> Next time
* BRAGA, Bruno , 2012-04-30, 10:03:
No need to mess with setup.py directly. Use dh_python2 to do the
packaging work for you, and rely on debian/rules to define the location
of your files. Read:
http://wiki.debian.org/Python/TransitionToDHPython2
Next time we'll read that dh_python2 is a cure
35 matches
Mail list logo
