Toshio Kuratomi wrote:
> Tarek Ziadé wrote:
>
>> Hello,
>>
>> This is a side discussion but quiet important ihmo.
>>
>> == Problem ==
>>
>> Some people complained about the fact that is was hard to extend
>> Distutils commands.
>> You end up rewriting the whole command most of the time.
>>
>> So
hellos,
Is it just me, or are these classifiers not as good as tags?
Should people really have to discuss and get approved what tags they put on
their software?
Seems like a big waste of everyones time, and doesn't result in as good a
database.
cheers,
2009/4/17 Tarek Ziadé
> 2009/4/16 "Mar
OK, just thinking through a little what it would mean to have an
installation tool in Python core...
On Thu, Apr 16, 2009 at 5:08 PM, Tarek Ziadé wrote:
> > But then I don't think Python should have a built-in installer or package
> > manager. There are excellent tools already available (Buildou
Tarek Ziadé wrote:
> Hello,
>
> This is a side discussion but quiet important ihmo.
>
> == Problem ==
>
> Some people complained about the fact that is was hard to extend
> Distutils commands.
> You end up rewriting the whole command most of the time.
>
> So what's a command ? It's a class that
On Wed, Apr 15, 2009 at 5:40 AM, Kevin Teague wrote:
> -1 for install/uninstall scripts in Distutils
>
> I'd argue that the scope of Distutils is already wide enough that it doesn't
> need to be extended to also be a "package manager" -- even if it's a really
> simple one.
>
> If a install/uninsta
Tarek Ziadé wrote:
> Hi,
>
> I am back on that problem with the code that builds the file list. The
> current Distutils trunk isn't working anymore with setuptools because
> of a recursive loop:
>
> distutils.sdist.run() -> setuptools.build_py.data_files ->
> setuptools.egg_info.run() -> distutil
2009/4/16 "Martin v. Löwis" :
>> I don't see it in the list (just LGPL without any version detail), I
>> am ccing this request to catalog-sig so
>> they can add it if they think it's wise
>
> How should this be done? As a separate classifier with the suffix v3,
> or as a subclassifier of LGPL?
>
L
Hi,
I am back on that problem with the code that builds the file list. The
current Distutils trunk isn't working anymore with setuptools because
of a recursive loop:
distutils.sdist.run() -> setuptools.build_py.data_files ->
setuptools.egg_info.run() -> distutils.sdist.add_defaults() ->
setuptool
> I don't see it in the list (just LGPL without any version detail), I
> am ccing this request to catalog-sig so
> they can add it if they think it's wise
How should this be done? As a separate classifier with the suffix v3,
or as a subclassifier of LGPL?
Regards,
Martin
_
Sorry, I meant to send this onlist. Reposting:
In the end, after some great suggestions and debugging help from Ian
Bicking, I managed to monkeypatch the monkeypatch to restore my
original script. I was using a hybrid approach (sometimes importing
distutils, sometimes setuptools) to avoid
At 01:03 PM 4/16/2009 -0400, Douglas Mayle wrote:
Hey everyone,
I'm having an annoying problem and I was directed here to
see if you
knew what could be done.
I'm using distutils for my package instead of setuptools
because it's
a command line app, and the half second that set
Hey everyone,
I'm having an annoying problem and I was directed here to see if you
knew what could be done.
I'm using distutils for my package instead of setuptools because it's
a command line app, and the half second that setup tools adds to each
launch for pkg_resource scanning is unac
Fadhley Salim wrote:
Has anybody managed to build an egg from the Numpy official release
binaries?
Unzip the superpack exe file (using something like 7-zip file manager).
Choose one of the 3 exe installers inside there, extract it and use
that. The nosse version probably works slowly on mos
Has anybody managed to build an egg from the Numpy official release
binaries? The Numpy developers recon that it's possible to do so. My
first attempt was not succsessfull:
D:\workspace\numpy>easy_install -zm
numpy-1.2.1-win32-superpack-python2.4.exe
Processing numpy-1.2.1-win32-superpack-python2
On Thu, Apr 16, 2009 at 4:13 PM, Carlos Tejo Alonso
wrote:
>
> Anyway, thanks for the link. About license classifiers, how can be define
> that the version of tht LGPL of the package is the version 3?
>
I don't see it in the list (just LGPL without any version detail), I
am ccing this request to
Hello,
> > - How can be configured the version of the metadata (AFAIK,
> rigth it is
> > always "Metadata-Version: 1.0")? I would like to use
> version 1.1 (PEP
> > 314. status: final) [2] or version 1.2 (PEP 345. status: draft) [3]
>
> If you use the fields mentioned in 1.1, Distutils will aut
On Thu, Apr 16, 2009 at 12:42 PM, Floris Bruynooghe
wrote:
> Do these improvements sound sensible? And if so should I create one
> patch for each (and two bug reports) or combine them into one patch?
They sound reasonable, please fill two differents bugs with your patches
and if you can, add so
On Wed, Apr 15, 2009 at 1:03 PM, Carlos Tejo Alonso
wrote:
> Hello,
Hello Carlos,
> - How can be configured the version of the metadata (AFAIK, rigth it is
> always "Metadata-Version: 1.0")? I would like to use version 1.1 (PEP
> 314. status: final) [2] or version 1.2 (PEP 345. status: draft) [3
Hello
Distutils allows you to use a handy --rpath option to the build_ext
command to add an RPATH value into the linked object. However some of
the semantics are not great IMHO.
For the first issue some background first. On SysV-like systems
(systems using the ELF binary format) the RPATH fiel
19 matches
Mail list logo
