Le samedi 30 janvier 2010 à 14:34 +1100, Ben Finney a écrit :
> * For the more usual case where the library is only of interest in your
> specific application, install it to an application-specific location
> (generally somewhere under ‘/usr/share/foo/’) and explicitly add that
> filesystem
Hi.
Sandro Tosi (30/01/2010):
> If you're decision is taken, I'd like to take the package back into
> DPMT repo and take care of them with the team.
Sure.
> If you still want to be in Uploaders it would be nice (but I'll
> understand if you don't),
No, thanks;
> and if you prefer to maintain
Hi Umang,
On Sat, Jan 30, 2010 at 5:24 AM, Umang wrote:
>
>foo-1.2.3.tar.gz
>foo-1.2.3/
>foo-1.2.3/bin/
>foo-1.2.3/bin/foo
>foo-1.2.3/foolib/
>foo-1.2.3/foolib/__init__.py
>...
>
> Now in foo-1.2.3/bin/foo how do I import foolib.wibble so that an installed
> foo (i.e.
On Sat, 2010-30-01 at 15:42 +1100, Ben Finney wrote:
> If the package is designed to be installed by distutils, it seems obtuse
> to expect it to work without using distutils. The point of distutils is
It is useful to be able to run a package without installing it for
development and testing.
> t
Guy Hulbert writes:
> On Sat, 2010-30-01 at 15:42 +1100, Ben Finney wrote:
> > If the package is designed to be installed by distutils, it seems
> > obtuse to expect it to work without using distutils.
>
> It is useful to be able to run a package without installing it for
> development and testin
On Sat, 2010-30-01 at 23:12 +1100, Ben Finney wrote:
> > It is useful to be able to run a package without installing it for
> > development and testing.
>
> Right. AFAIK there's no way to do that with Distutils (yet).
I'm currently working on a perl application and the same is true for
Module::Bu
On 30/01/10 13:12, Ben Finney wrote:
Guy Hulbert writes:
On Sat, 2010-30-01 at 15:42 +1100, Ben Finney wrote:
If the package is designed to be installed by distutils, it seems
obtuse to expect it to work without using distutils.
It is useful to be able to run a package without installing it
There's no particular message I want to reply to: just wanted to signal
that I find the structure
./appname
./appnamelib/__init__.py
./appnamelib/...
./stuff/appname.svg
./stuff/appname.glade
./stuff/...
the most practical to get appname running in both installed and
uninstalled mode - which I d
On Sat, 2010-30-01 at 15:32 +0100, Pietro Battiston wrote:
> ./appname
> ./appnamelib/__init__.py
appending lib to everything is really ugly* ... is it because
./appname.py
./appname/__init__.py
fails to work ?
[*] And the debian perl group pre-pend 'lib' to all the packaged perl
modules so yo
Le samedi 30 janvier 2010 à 15:32 +0100, Pietro Battiston a écrit :
> Then, in my apps, I put
>
> not_installed_dir = os.path.dirname(os.path.realpath(__file__))
Every time you use introspection features (like __file__) for something
else than introspection, you have completely failed somewhere
On 30/01/10 20:12, Guy Hulbert wrote:
appending lib to everything is really ugly* ... is it because
./appname.py
./appname/__init__.py
fails to work ?
[*] And the debian perl group pre-pend 'lib' to all the packaged perl
modules so you'd have libappnamelib-V.deb
Yes. I asked this question
On 30/01/10 20:02, Pietro Battiston wrote:
What I ignore is: is there some smarter (than [sys.prefix, sys.prefix +
'/local']) way to check possible _installed_ locations?
You're not _supposed_ to look in sys.prefix + '/local'. (i.e.
/usr/local) If you used a pure version of distutils, then e
On Sat, 2010-30-01 at 21:03 +0530, Umang wrote:
> However, my
> foolib will have 99.9% of my code. foolib _is_ my program, it's not a
Why not just have foo.py then ?
There *are* python programs written this way. I think you can still use
them as libraries if you use the __main__ convention at
On 30/01/10 21:10, Guy Hulbert wrote:
Why not just have foo.py then ?
That would be too messy. For the one full package I've written in Python
since I learned to code Python, there is a gui that manages everything
that happens in the gui. However, the gui class itself requires uses two
oth
Il giorno sab, 30/01/2010 alle 21.10 +0530, Umang ha scritto:
> On 30/01/10 20:02, Pietro Battiston wrote:
> > What I ignore is: is there some smarter (than [sys.prefix, sys.prefix +
> > '/local']) way to check possible _installed_ locations?
> >
> You're not _supposed_ to look in sys.prefix +
Hello,
Guy Hulbert wrote:
> appending lib to everything is really ugly* ... is it because
>
> ./appname.py
> ./appname/__init__.py
>
> fails to work ?
Yes! If you import appname from the appname.py, it will try to import
itself ! What I do right now is the following :
./scripts/appname
./appna
Il giorno sab, 30/01/2010 alle 09.42 -0500, Guy Hulbert ha scritto:
> On Sat, 2010-30-01 at 15:32 +0100, Pietro Battiston wrote:
> > ./appname
> > ./appnamelib/__init__.py
>
> appending lib to everything is really ugly* ...
I don't find ugly to signal that a library is a library...
(regardless
Il giorno sab, 30/01/2010 alle 16.14 +0100, Josselin Mouette ha scritto:
> Le samedi 30 janvier 2010 à 15:32 +0100, Pietro Battiston a écrit :
> > Then, in my apps, I put
> >
> > not_installed_dir = os.path.dirname(os.path.realpath(__file__))
>
> Every time you use introspection features (like _
Le samedi 30 janvier 2010 à 21:40 +0100, Pietro Battiston a écrit :
> In my ignorance, what I've exposed is the only way I know to get things
> working as I want, so I'll be happy to get in touch with better
> designs... for me, so far, __file__ may very well have been a hack, but
> certainly not
On Jan 29, 2010, at 11:42 PM, Ben Finney wrote:
> Umang writes:
>
>> What I am talking about is the upstream tarball that, when extracted
>> into a directory, can run without being installed using distutils.
>
> If the package is designed to be installed by distutils, it seems obtuse
> to expec
On Jan 30, 2010, at 4:56 PM, Josselin Mouette wrote:
> Maybe you don’t understand it is a plague, because you are not trying to
> package the things you write with __file__ for a distribution. The
> location of module files on the system should be a hidden implementation
> detail. Because of __fil
Josselin Mouette writes:
> Going back to the topic, please try using autoconf, waf or even cmake to
> distribute your modules. These tools were designed to abstract things
> like filesystem locations and to generate everything needed at
> installation time.
The focus of autoconf and CMake, thoug
Il giorno sab, 30/01/2010 alle 22.56 +0100, Josselin Mouette ha scritto:
> Le samedi 30 janvier 2010 à 21:40 +0100, Pietro Battiston a écrit :
> > In my ignorance, what I've exposed is the only way I know to get things
> > working as I want, so I'll be happy to get in touch with better
> > designs
/me strongly discourages using __file__ and waf
regarding __file__ - things might change soon (see this[1] thread)
[1] http://mail.python.org/pipermail/distutils-sig/2009-November/014424.html
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.grif
Le samedi 30 janvier 2010 à 17:22 -0500, Barry Warsaw a écrit :
> Do you feel the same way about pkg_resources?
pkg_resources allows to do things correctly, but I find it too complex;
it’s no wonder why people still hack stuff around __file__: it’s much
simpler.
Basically, I’d say it tries to ad
On Jan 31, 2010, at 01:09 AM, Josselin Mouette wrote:
>pkg_resources allows to do things correctly, but I find it too complex;
>it’s no wonder why people still hack stuff around __file__: it’s much
>simpler.
I think it's not so much that pkg_resources is complex, but that it has a lot
of extra AP
2010/1/29 Piotr Ożarowski :
> * replace python-zopeinterface with python-zope.interface in Depends
> * please fix lintian warnings:
All done, committed to svn and re-uploaded to mentors.debian.net.
--
Elliot Murphy | https://launchpad.net/~statik/
--
To UNSUBSCRIBE, email to debian-python-requ.
27 matches
Mail list logo
