On Wed, Oct 1, 2008 at 2:12 AM, Brian Cameron <[EMAIL PROTECTED]> wrote:
> I am having troubles working with setuptools on Solaris. The Solaris
> operating system normally installs modules as packages which contain
> binaries. This is unlike other Linux operating systems where, for
> exmaple, an
Le mardi 30 septembre 2008 à 16:57 -0500, Dave Peterson a écrit :
> But we already have a separation between project name and module names
> that are contained within that project. We don't currently declare
> dependencies on the module names but on the project name. i.e. a
> dependency on Hard
Josselin Mouette wrote:
>
> As I understand PEP 345, it proposes to introduce dependencies based on
> module names, not on project names. This is one of the key points where
> it is superior to setuptools; especially, if developers correctly change
> the module name when changing the API, the depen
Le mercredi 01 octobre 2008 à 17:24 +0900, David Cournapeau a écrit :
> I mean, when I build my C program against the glibc, I never have to
> change my compiler commands depending on which version of glibc I want.
Indeed, and the reason is that *functions never disappear from the
glibc*.
> Inter
Josselin Mouette wrote:
>
> Indeed, and the reason is that *functions never disappear from the
> glibc*.
Yes and no. If you remove a function, you're indeed screwed, because you
can't handle versioning in the header. But you can handle versioning in
libraries at the link step, and file name of the
Hello
I know it is a bad practice for a recipe to return some paths that
contains important data in the install() method,
because zc.buildout might remove them.
Nevertheless, it happens from time to time that a developer lose some
content because of a misconfiguration,
or a zealous recipe. That i
I feel foolish now. The bit I was always missing was "-m" which stops
easy_install complaining about "." not being on PYTHONPATH.
I really think this should be more obvious though. Something this basic
could do with it's own option. It would help demystify what
easy_install does. The basic u
Hello
I have followed most of the threads from the past days, and we talked
a lot on IRC with people from Fedora, Debian, Enthought, TG2 on
possible enhancements
While the other threads are continuing in deeper details, I would like
to start a fresh thread were people don't have to re-read everyth
Hi,
I've been using distutils for a while now, but today I'm running
into what seems to be the "minimal strange issue". I want to in-
stall a single Python module without anything else, no package
around it, which resides in a source subdirectory of the main
project directory. My layout looks lik
As a follow up to the thread named [Fwd: Re: Announcing distribute
project] where Tarek ended up proposing a package_info.py file or a
PackageInfo class:
http://www.logilab.org/cgi-bin/hgwebdir.cgi/logilab/common/file/02993a85ee3c/__pkginfo__.py
--
Nicolas Chauvat
logilab.fr - services en infor
New submission from chris <[EMAIL PROTECTED]>:
Given a set of packages and their dependencies, process all dependencies, find
the intersection, and install dependencies based on the results. The current
behavior is to find the best match for each individual package. This can result
in breakages w
On Tue, Sep 30, 2008 at 7:51 PM, Nicolas Chauvat
<[EMAIL PROTECTED]> wrote:
> As a follow up to the thread named [Fwd: Re: Announcing distribute
> project] where Tarek ended up proposing a package_info.py file or a
> PackageInfo class:
>
> http://www.logilab.org/cgi-bin/hgwebdir.cgi/logilab/common/
On Wed, Oct 1, 2008 at 8:10 AM, Tarek Ziadé <[EMAIL PROTECTED]> wrote:
> 8/ the requires-python field is rarely used by people, so unless you
> try the package, you don't know when it is a source
>distribution, if it is going to run on various python versions.
What requires-python field?
I do
-On [20081001 14:10], Tarek Ziadé ([EMAIL PROTECTED]) wrote:
>I have followed most of the threads from the past days, and we talked
>a lot on IRC with people from Fedora, Debian, Enthought, TG2 on
>possible enhancements
Just a note: do not forget the BSD Unix systems when it comes to
On Wed, Oct 1, 2008 at 3:08 PM, Fred Drake <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 1, 2008 at 8:10 AM, Tarek Ziadé <[EMAIL PROTECTED]> wrote:
>> 8/ the requires-python field is rarely used by people, so unless you
>> try the package, you don't know when it is a source
>>distribution, if it is
On Wed, Oct 1, 2008 at 3:16 PM, Jeroen Ruigrok van der Werven
<[EMAIL PROTECTED]> wrote:
> -On [20081001 14:10], Tarek Ziadé ([EMAIL PROTECTED]) wrote:
>>I have followed most of the threads from the past days, and we talked
>>a lot on IRC with people from Fedora, Debi
-On [20081001 15:24], Tarek Ziadé ([EMAIL PROTECTED]) wrote:
>Yes indeed, a BSD packager could be helpfull in the discussion. Are
>you able to help us in this ?
I used to be a FreeBSD and DragonFly BSD committer and I still use Python
mostly on BSD systems. I am sure Trent Nelson could als
Andrew Price wrote:
> Hi,
>
> Distutils has made my life easier as an python application author and packager
> for some time but when it comes to generating and distributing message
> catalogues for translations, things get unexpectedly tricky.
>
> It would be nice to be able to do something like
-On [20081001 16:28], Toshio Kuratomi ([EMAIL PROTECTED]) wrote:
>> and have distutils do the right thing with the .po files at build time
>> (generate .mo files from them) and at install time (install them into
>> PREFIX/share/locales/LC_MESSAGES/, or wherever the distribution i
At 02:10 PM 10/1/2008 +0200, Tarek Ziadé wrote:
Proposals
this is also a synthezis of what I hurd, and some elements I have
added to respect the needs that were expressed.
0/ a lot of work can be done to clean distutils, no matter what is
decided (another PEP is built for that) cleanni
At 02:10 PM 10/1/2008 +0200, Dinu Gherman wrote:
Hi,
I've been using distutils for a while now, but today I'm running
into what seems to be the "minimal strange issue". I want to in-
stall a single Python module without anything else, no package
around it, which resides in a source subdirectory
At 01:12 AM 10/1/2008 -0500, Brian Cameron wrote:
I am having troubles working with setuptools on Solaris. The
Solaris operating system normally installs modules as packages which contain
binaries. This is unlike other Linux operating systems where, for
exmaple, an RPM would download the sour
On Wed, Oct 1, 2008 at 7:29 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> I'm -1 on all of the above. I think we need a standard for tools interop
> (ala WSGI), not implementation tweaks for the existing tools. I also think
> that a concrete metadata format proposal is premature at this time; w
You guys are fairly into you debate so hopefully I don't interject
something that's already been gone over :-)
Chris Withers wrote:
> Matthias Klose wrote:
Install debian and get back to productive tasks.
>>> This is an almost troll-like answer.
>>> See page 35 of the presentation.
>>
>> I di
Brian Cameron wrote:
>
You're actually describing pretty much exactly how rpm works :-)
As such, the Fedora Project has had to deal with many of the same issues
in packaging python packages as you're running into. This pairs of
pages may help you:
http://fedoraproject.org/wiki/Packaging/Python
Jeroen Ruigrok van der Werven wrote:
> -On [20081001 16:28], Toshio Kuratomi ([EMAIL PROTECTED]) wrote:
>>> and have distutils do the right thing with the .po files at build time
>>> (generate .mo files from them) and at install time (install them into
>>> PREFIX/
At 07:55 PM 10/1/2008 +0200, Tarek Ziadé wrote:
On Wed, Oct 1, 2008 at 7:29 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> I'm -1 on all of the above. I think we need a standard for tools interop
> (ala WSGI), not implementation tweaks for the existing tools. I also think
> that a concrete met
At 11:00 AM 10/1/2008 -0700, Toshio Kuratomi wrote:
I have no love for how pkg_resources implements this (including the API)
but the idea of retrieving data files, locales, config files, etc from
an API is good. For packages to be coded that conform to the File
Hierachy Standard on Linux, the AP
Phillip & Others:
Thanks so much for taking the time to answer my questions, I am a
newbie to setuptools so I apologize if I was just being thick.
Phillip, your suggested solution of using --root solved my problem. I
was previously using --prefix instead, but using --root creates the
packages
-On [20081001 20:26], Toshio Kuratomi ([EMAIL PROTECTED]) wrote:
>That's good to know. One of our Turbogears applications uses Babel and
>it definitely doesn't install to the right place. I'd love to fix it to
>take advantage of Babel' properly. Would y
Hi,
On 01/10/08 15:35, Jeroen Ruigrok van der Werven wrote:
> -On [20081001 16:28], Toshio Kuratomi ([EMAIL PROTECTED]) wrote:
>> This has been a big deal for some applications I work on. Our first cut
>> was to add new Build and InstallData command classes.
>
> Actu
On Wed, Oct 01, 2008 at 02:28:07PM -0400, Phillip J. Eby wrote:
> In order for the *real* goal to be achieved (i.e., a flourishing
> build/install system for Python), widespread participation and buy-in is
> required. If the OS people or the big package people (e.g. Zope Corp.,
> Enthought) or
At 02:15 PM 10/1/2008 -0500, chris wrote:
Is it just me, or does --root work the same way
--single-version-externally-managed does, just with the addition of
the directory?
--root automatically triggers --single-version-externally-managed, in
addition to distutils' normal handling of --root.
Le mercredi 01 octobre 2008 à 11:00 -0700, Toshio Kuratomi a écrit :
> 1) The heuristic encourages bad practices. Versions need to be parsed
> by computer programs (package managers, scripts that maintain
> repositories, etc). Not all of those are written in python. Having
> things other than le
Le mercredi 01 octobre 2008 à 14:39 -0400, Phillip J. Eby a écrit :
> > We need to be able to mark locale, config, and data files in
> >the metadata.
>
> Sure... and having a standard for specifying that kind of
> application/system-level install stuff is great; it's just entirely
> outside t
On Oct 1, 2008, at 11:25 AM, Toshio Kuratomi wrote:
Jeroen Ruigrok van der Werven wrote:
-On [20081001 16:28], Toshio Kuratomi ([EMAIL PROTECTED]) wrote:
and have distutils do the right thing with the .po files at build
time
(generate .mo files from them) and at install time (install them
Jeroen Ruigrok van der Werven wrote:
> -On [20081001 20:26], Toshio Kuratomi ([EMAIL PROTECTED]) wrote:
>> That's good to know. One of our Turbogears applications uses Babel and
>> it definitely doesn't install to the right place. I'd love to fix it to
>&g
At 09:40 PM 10/1/2008 +0200, Josselin Mouette wrote:
Le mercredi 01 octobre 2008 à 14:39 -0400, Phillip J. Eby a écrit :
> > We need to be able to mark locale, config, and data files in
> >the metadata.
>
> Sure... and having a standard for specifying that kind of
> application/system-level
Phillip J. Eby wrote:
> At 11:00 AM 10/1/2008 -0700, Toshio Kuratomi wrote:
>> I have no love for how pkg_resources implements this (including the API)
>> but the idea of retrieving data files, locales, config files, etc from
>> an API is good. For packages to be coded that conform to the File
>>
Phillip J. Eby wrote:
> At 09:40 PM 10/1/2008 +0200, Josselin Mouette wrote:
>> Le mercredi 01 octobre 2008 à 14:39 -0400, Phillip J. Eby a écrit :
>> > > We need to be able to mark locale, config, and data files in
>> > >the metadata.
>> >
>> > Sure... and having a standard for specifying tha
Toshio Kuratomi wrote:
Another idea would be to have API information stored in metadata but not
in the package name. That way marketing can have a big party for
MyLib-2.0 but the API metadata has API_Revision: 32.
+1. (I think this idea has been mentioned before too.) We should
definit
Josselin Mouette wrote:
Le mercredi 01 octobre 2008 à 14:39 -0400, Phillip J. Eby a écrit :
To be clear, I mean here that a "file" (as opposed to a resource) is
something that the user is expected to be able to read or copy, or
modify. (Whereas a resource is something that is entirely inter
Philip Jenvey wrote:
>
> On Oct 1, 2008, at 11:25 AM, Toshio Kuratomi wrote:
>
>> Jeroen Ruigrok van der Werven wrote:
>>> -On [20081001 16:28], Toshio Kuratomi ([EMAIL PROTECTED]) wrote:
>>>>> and have distutils do the right thing with the .po files at bu
Dave Peterson wrote:
> Josselin Mouette wrote:
>> Le mercredi 01 octobre 2008 à 14:39 -0400, Phillip J. Eby a écrit :
>>
>>> To be clear, I mean here that a "file" (as opposed to a resource) is
>>> something that the user is expected to be able to read or copy, or
>>> modify. (Whereas a resou
At 03:14 PM 10/1/2008 -0700, Toshio Kuratomi wrote:
resources, as I said needs to be defined. You're saying here that a
resource is something internal to the library. A "file" is something
that a user can read, copy, or modify.
I should probably clarify that I mean "unmediated by the
program
Josselin Mouette wrote:
Le mardi 30 septembre 2008 à 17:20 +0200, Tarek Ziadé a écrit :
>
> I mean, if you change a public API of your package , you *have* to
> change its name ?
Yes, this is the requirement for C libraries, and we try to enforce it
as well for other languages.
Things are so
On Wed, Oct 1, 2008 at 8:28 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 07:55 PM 10/1/2008 +0200, Tarek Ziadé wrote:
>>
>> On Wed, Oct 1, 2008 at 7:29 PM, Phillip J. Eby <[EMAIL PROTECTED]>
>> wrote:
>> > I'm -1 on all of the above. I think we need a standard for tools
>> > interop
>> > (al
Phillip J. Eby wrote:
> At 03:14 PM 10/1/2008 -0700, Toshio Kuratomi wrote:
>> resources, as I said needs to be defined. You're saying here that a
>> resource is something internal to the library. A "file" is something
>> that a user can read, copy, or modify.
>
> I should probably clarify that
Toshio Kuratomi wrote:
this is what I was afraid of. This is definitely not a definition
of resource-only that has meaning for Linux distributions. None of the
data in /usr/share is user-modifiable
In that case it must be there because it's architecture-independent,
right?
But by that crit
David Cournapeau wrote:
> Josselin Mouette wrote:
>> Indeed, and the reason is that *functions never disappear from the
>> glibc*.
>
> Yes and no. If you remove a function, you're indeed screwed, because you
> can't handle versioning in the header. But you can handle versioning in
> libraries at t
At 07:14 PM 10/1/2008 -0700, Toshio Kuratomi wrote:
In terms of implementation I'd much rather see something less centered
on the egg being the right way and the filesystem being a secondary
concern.
Eggs don't have anything to do with it; in Python, it's simply common
sense to put static reso
Greg Ewing wrote:
> Toshio Kuratomi wrote:
>
>> this is what I was afraid of. This is definitely not a definition
>> of resource-only that has meaning for Linux distributions. None of the
>> data in /usr/share is user-modifiable
>
> In that case it must be there because it's architecture-indep
Toshio Kuratomi <[EMAIL PROTECTED]> writes:
> 3) /usr/share has two purposes/criteria[1]_: architecture
> independent and datafiles. /usr/lib has two criteria[2]_:
> architecture independent and libraries. With .py{,c,o} we have both
> architecture indepedence and a library. So the criteria is in
53 matches
Mail list logo
