On Sun, Nov 15, 2009 at 3:44 AM, Jeremy Kloth jeremy.kl...@gmail.com wrote:
[..]
So did you end up changing the way options are passed to the commands,
or do you just have a specific config command that looks over other
options passed to the other commands ?
It is done with the 'config'
On Sun, Nov 15, 2009 at 7:24 AM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Tarek Ziadé wrote:
And have the community create new ExtensionBuilder subclasses that
could be registered like command.
I don't see a need for registering anything. You should
just be able to explicitly say what
Tarek Ziadé wrote:
But the result is similar, and explicit imports should work too, so
maybe registeries
are just sugar on the top of something we first need to make work.
It's completely unnecessary sugar, if you ask me.
I don't see what's bad about importing functionality
you want to use.
At 03:13 PM 11/11/2009 +0100, Tarek Ziadé wrote:
But you call it with install in your example, meaning that is is
called at install time, right ?
Or it is just that you want to get the --prefix value finalized and
computed by the install
command. If it's the later, I guess you will be able to
On Fri, Nov 13, 2009 at 3:46 PM, Jeremy Kloth jeremy.kl...@gmail.com wrote:
[..]
The exact thing being described has been done in 4Suite for 6 years (along
with many other distutils improvements). Feel free to take or discuss or
request help with any of the features/additions (like FHS layout
On Wed, Nov 11, 2009 at 11:49 PM, Pauli Virtanen p...@iki.fi wrote:
[..]
Just to throw some wild, perhaps obvious, and definitely unasked-for
ideas in the air (especially as I can't promise I can give any sustained
help here :/ ):
I suppose one option would be to factor *everything* related
On Saturday 14 November 2009 05:14:05 pm Tarek Ziadé wrote:
On Fri, Nov 13, 2009 at 3:46 PM, Jeremy Kloth jeremy.kl...@gmail.com
The way we've impl'd 'config' was as a prerequisite for 'build', just as
'build' is for 'install'. If any of the options stored by the 'config'
command are
Tarek Ziadé wrote:
And have the community create new ExtensionBuilder subclasses that
could be registered like command.
I don't see a need for registering anything. You should
just be able to explicitly say what tool to use for each
stage of the process.
I envisage something like this:
On Fri, Nov 13, 2009 at 6:22 AM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
Tarek Ziadé wrote:
A deprecation warning would be added in install, if it finds a local
option, rather
than a global. Meaning both would work in 2.7/3.2.
If changing the command line in incompatible ways
On Fri, Nov 13, 2009 at 1:18 PM, Floris Bruynooghe
floris.bruynoo...@gmail.com wrote:
[..]
Is that scraping, or just preparing finalized options using configure ?
Meaning other command would just have to get them when they run, if present ?
How would that work ? configure would create a file ?
On Fri, Nov 13, 2009 at 11:26:23AM +0100, Tarek Ziadé wrote:
On Fri, Nov 13, 2009 at 6:22 AM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
Tarek Ziadé wrote:
A deprecation warning would be added in install, if it finds a local
option, rather
than a global. Meaning both would work
On Fri, Nov 13, 2009 at 9:46 PM, Tarek Ziadé ziade.ta...@gmail.com wrote:
On Fri, Nov 13, 2009 at 1:18 PM, Floris Bruynooghe
floris.bruynoo...@gmail.com wrote:
[..]
Is that scraping, or just preparing finalized options using configure ?
Meaning other command would just have to get them when
On Fri, Nov 13, 2009 at 1:52 PM, David Cournapeau courn...@gmail.com wrote:
On Fri, Nov 13, 2009 at 9:46 PM, Tarek Ziadé ziade.ta...@gmail.com wrote:
On Fri, Nov 13, 2009 at 1:18 PM, Floris Bruynooghe
floris.bruynoo...@gmail.com wrote:
[..]
Is that scraping, or just preparing finalized
On Friday 13 November 2009 06:44:37 am Tarek Ziadé wrote:
Here's my proposal for this to happen, if you (and others) want to
contribute:
Let's build this new configure command in Distribute 0.7, together
with the APIs to read/write the data.
Then let's change the other commands
ke, 2009-11-11 kello 21:42 +0100, Tarek Ziadé kirjoitti:
[clip]
Do you mean, an Extension that would require several compilers ?
I was thinking of a one-to-one relation between an Extension and a
compiler type, even if there are are multiple source files (in different
languages)
for this
On Thu, Nov 12, 2009 at 5:30 AM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
Greg Ewing wrote:
As far as I can tell David seems to be saying that
instantiating a class for every file in the system
would be too much overhead.
I'm not convinced about that -- make builds a dependency
Thu, 12 Nov 2009 10:54:41 +0100, Tarek Ziadé wrote:
[clip]
get_install_paths('FOO')
And that's the API we want to add in sysconfig, roughly.
That does not solve the problem about getting FOO in the first place
when calling get_install_path.
Why that ? where FOO comes from ? if it's an
Tarek Ziadé schrieb:
For the documentation part I am afraid it will be messy for the end
users trying to package apps in Python *until* all PEPs
have made it into Python.
Although, as Ian Bicking says: we could write today some kind of
all-in-one tutorial so end-users can work out without
On Thu, Nov 12, 2009 at 12:31 PM, Pauli Virtanen pav...@iki.fi wrote:
Thu, 12 Nov 2009 10:54:41 +0100, Tarek Ziadé wrote:
[clip]
get_install_paths('FOO')
And that's the API we want to add in sysconfig, roughly.
That does not solve the problem about getting FOO in the first place
when
On Thu, Nov 12, 2009 at 9:42 PM, John Kleint jkle...@gmail.com wrote:
Tarek Ziadé schrieb:
For the documentation part I am afraid it will be messy for the end
users trying to package apps in Python *until* all PEPs
have made it into Python.
Although, as Ian Bicking says: we could write today
On Fri, Nov 13, 2009 at 7:12 AM, Tarek Ziadé ziade.ta...@gmail.com wrote:
On Thu, Nov 12, 2009 at 12:31 PM, Pauli Virtanen pav...@iki.fi wrote:
Thu, 12 Nov 2009 10:54:41 +0100, Tarek Ziadé wrote:
[clip]
get_install_paths('FOO')
And that's the API we want to add in sysconfig, roughly.
That
On Fri, Nov 13, 2009 at 1:08 AM, David Cournapeau courn...@gmail.com wrote:
[..]
$ python setup.py --prefix=foo cmd1 cmd1 etc
and the result would be in Distribution.options = {'path1': xxx, 'path2': xx}
This is a major change in distutils behavior, so we need to solve the
following issues:
On Thu, Nov 12, 2009 at 11:45 PM, David Cournapeau courn...@gmail.com wrote:
[..]
I think I was confusing with my rpath example, which may be the source
of our misunderstanding. I don't want to add a --prefix option to
build_ext. I want to support the following user cases:
python setup.py
On Nov 12, 2009, at 12:42 PM, John Kleint wrote:
I have the start of such a document, derived from my own recent
experience pulling together all the information needed to release a
new Python project. It's aimed at people new to packaging and
possibly open source in general, so it's broader
Tarek Ziadé wrote:
A deprecation warning would be added in install, if it finds a local
option, rather
than a global. Meaning both would work in 2.7/3.2.
If changing the command line in incompatible ways is acceptable, what do
you think of scrapping the commands (at the UI level only)
On Wed, Nov 11, 2009 at 7:14 AM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
David Cournapeau wrote:
One of the
main argument to avoid rewrite is that you will end up doing the same
mistakes, and old code is more complicated because it has been tested.
But here, we know what a good design
On Wed, Nov 11, 2009 at 7:05 AM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
[..]
Exactly. The fact that we in numpy consider distutils backward
compatibility not worth the cost, even though we are most likely the
most tied up with distutils, is quite telling about the state of
To the people who wants a rewrite, two things need to be asked:
1. Do you think the new PEPs in development should be followed? In
that case, what is the benefit of rewriting, instead of fixing?
2. When are you done? :-) I'm not being rude, but this is open source.
There is no Someone that can
Tarek Ziadé wrote:
On Wed, Nov 11, 2009 at 7:05 AM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
[..]
Exactly. The fact that we in numpy consider distutils backward
compatibility not worth the cost, even though we are most likely the
most tied up with distutils, is quite telling
On Wed, Nov 11, 2009 at 10:46 AM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
[..]
Example: how to retrieve the install prefix in setup.py. You need a good
understanding of distutils to understand why it is so complicated, and
the example shows almost everything that's wrong in
On Wed, 11 Nov 2009 19:14:42 +1300, Greg Ewing
greg.ew...@canterbury.ac.nz
wrote:
Also, it seems to me that in this case, the basic
architecture of distutils is already so full of
mistakes that there just isn't an incremental way
of getting to a better place, especially given the
requirement
Tarek Ziadé ziade.tarek at gmail.com writes:
Also, notice that we are in the process of adding a new python module
in the stdlib, called
sysconfig, that will contains all installation paths scheme for all
supported platforms.
I don't think we are talking about the same thing. If the pb
On Nov 11, 2009, at 4:39 AM, Lennart Regebro wrote:
If nobody is willing to write the code, the code is not needed.
I think it would be more accurate to say that nobody is deciding that
the need is sufficient to invest the resources to fill it.
There are lots of things that many people
2009/11/11 sstein...@gmail.com sstein...@gmail.com:
On Nov 11, 2009, at 4:39 AM, Lennart Regebro wrote:
If nobody is willing to write the code, the code is not needed.
I think it would be more accurate to say that nobody is deciding that the
need is sufficient to invest the resources to fill
On Wed, Nov 11, 2009 at 1:31 PM, David Cournapeau courn...@gmail.com wrote:
[..]
AFAIK, there is only one way to get the information: since the --prefix is
only
known once install.finalize_options() has run, you need to call the method
from
build_clib.
Naive code could be something like
On Nov 11, 2009, at 7:38 AM, Lennart Regebro wrote:
2009/11/11 sstein...@gmail.com sstein...@gmail.com:
On Nov 11, 2009, at 4:39 AM, Lennart Regebro wrote:
If nobody is willing to write the code, the code is not needed.
I think it would be more accurate to say that nobody is deciding
On Wed, Nov 11, 2009 at 10:16 PM, Tarek Ziadé ziade.ta...@gmail.com wrote:
Ouch, That's not to be done. Something is wrong with your build_clib
design here.
You are roughly calling install as a sub command.
Yes, it is wrong from distutils POV, but there is no other solution
to get the
On Wed, Nov 11, 2009 at 2:48 PM, David Cournapeau courn...@gmail.com wrote:
If you want to have install options for your command, and if your
command is about installing,
I did not say my command was about installing - it does not install
anything. To be complete, we do not use this in
On Wed, Nov 11, 2009 at 14:16 +0100, Tarek Ziadé wrote:
On Wed, Nov 11, 2009 at 1:31 PM, David Cournapeau courn...@gmail.com wrote:
But, at the end, since an option is either global, either specific to
a command, I guess a simple API in the command class should be enough
to avoid this hack:
2009/11/11 sstein...@gmail.com sstein...@gmail.com:
I don't think it's redundant because a lot of needs in Python go unmet,
not due to people's inability or unwillingness, but due to a lack of
time/funding which amount to the same thing.
People *want* a lot of things. But if they truly *need*
In line with this discussion, I found a document that details the aspects
of CPAN that can be used for writing packaging systems in other languages.
The author says: over the years people from at least Python, Ruby, and
Java communities have approached me or other core CPAN people to ask
ke, 2009-11-11 kello 16:47 +0100, Tarek Ziadé kirjoitti:
[clip]
If it's the later, I guess you will be able to use the
upcoming sysconfig module,
that gives you the install schemes, depending on
sys.prefix/sys.exec_prefix.
Where is the sysconfig sources ? I don't see it in bitbucket.
On Wed, Nov 11, 2009 at 9:22 PM, Pauli Virtanen p...@iki.fi wrote:
ke, 2009-11-11 kello 16:47 +0100, Tarek Ziadé kirjoitti:
[clip]
If it's the later, I guess you will be able to use the
upcoming sysconfig module,
that gives you the install schemes, depending on
Tarek Ziadé wrote:
If the answer to that solution is just: Distutils sucks anyways..,
it is not really helpfull imho..
I don't see the point to write Distutils from scratch, instead of
making it evolve.
If you can see a way to get from the current distutils
code to something with a
On 2009-11-11 15:02 PM, Greg Ewing wrote:
Tarek Ziadé wrote:
If the answer to that solution is just: Distutils sucks anyways..,
it is not really helpfull imho..
I don't see the point to write Distutils from scratch, instead of
making it evolve.
If you can see a way to get from the current
On Wed, Nov 11, 2009 at 10:36 PM, Robert Kern robert.k...@gmail.com wrote:
[..]
It does feel something like that. The build system is just one of the
problems with distutils' internals, in my experience. You can think of the
rest of distutils as a little application framework for command line
On 2009-11-11 15:59 PM, Tarek Ziadé wrote:
On Wed, Nov 11, 2009 at 10:36 PM, Robert Kernrobert.k...@gmail.com wrote:
[..]
It does feel something like that. The build system is just one of the
problems with distutils' internals, in my experience. You can think of the
rest of distutils as a
On Thu, Nov 12, 2009 at 5:42 AM, Tarek Ziadé ziade.ta...@gmail.com wrote:
I am not sure he wants FOO, I think he wants all installation paths,
that gets built
by the install command with the provided FOO root prefix.
that could be in pseudo code:
get_install_paths('FOO')
And that's the
Hi Greg,
On Thu, 12 Nov 2009 10:02:18 +1300, Greg Ewing
greg.ew...@canterbury.ac.nz
wrote:
What we need right now, I think, is some discussion
about a new API, unconstrained by any considerations of
backwards compatibility
A new API isn't so hard, but like anything it takes time
and
On Thu, Nov 12, 2009 at 12:03 AM, David Cournapeau courn...@gmail.com wrote:
On Thu, Nov 12, 2009 at 5:42 AM, Tarek Ziadé ziade.ta...@gmail.com wrote:
I am not sure he wants FOO, I think he wants all installation paths,
that gets built
by the install command with the provided FOO root
On Wed, Nov 11, 2009 at 11:22 PM, Robert Kern robert.k...@gmail.com wrote:
[..]
To get to one real specific problem, let's consider build_src. build_src is
a new subcommand in numpy.distutils that builds C extension sources from
other files. We use this to hook in f2py's wrapper generator and
Robert Kern wrote:
With all respect to Greg Ward and the rest of the original distutils
authors, it was a fantastic improvement over the state of affairs ten
years ago, but we've learned a lot about application frameworks and
about building software since then.
I think we knew more about it
Tarek Ziadé wrote:
On Thu, Nov 12, 2009 at 12:03 AM, David Cournapeau courn...@gmail.com wrote:
You cannot obtain this with classes and objects (especially when you
start talking about performance: thousand of source files for one
extension is not a crazy usercase).
Sorry, I am getting
Greg Ewing wrote:
As far as I can tell David seems to be saying that
instantiating a class for every file in the system
would be too much overhead.
I'm not convinced about that -- make builds a dependency
graph with a node for every target before it goes
to work, and I think scons does
Tarek Ziadé wrote:
On Tue, Nov 10, 2009 at 2:31 AM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
[..]
If you want to support a new source/target (say assembler), you need to
deal at this stage (or use hacks to deal with the new file extension
you want to deal with, and remove it
David Cournapeau wrote:
One of the
main argument to avoid rewrite is that you will end up doing the same
mistakes, and old code is more complicated because it has been tested.
But here, we know what a good design is like as other languages have
vastly superior solutions to this problem.
Also,
Greg Ewing wrote:
Also, it seems to me that in this case, the basic
architecture of distutils is already so full of
mistakes that there just isn't an incremental way
of getting to a better place, especially given the
requirement of not breaking any existing setup.py
scripts together with
Ian Bicking wrote:
I don't think changing distutils to improve error output would be hard
at all. It looks like there's a line in distutils.core that catches
these exceptions (and doesn't look like it actually catches all
exceptions?), and that can just be fixed.
I agree this is one of the
On Sat, 07 Nov 2009 07:37:37 -0800, Tarek Ziadé ziade.ta...@gmail.com
wrote:
The solution for a better PyPI:
- more checks, more restrictions
- every package maintainer uploading something to PyPI
should have a certain attitude that PyPI is a public
resource where the content should
I suggest that we check for valid metadata on the uploaded sdists at the
least. If you visit
http://pypm.activestate.com/ - most failed packages are due to the fact the
sdist
uploaded by the author misses certain files such as README.txt (that is read
by setup.py)
or setup.py/PKG-INFO
On 11/9/09, David Cournapeau da...@ar.media.kyoto-u.ac.jp wrote:
[...]
Some things are fixable in distutils: for example, to build things, you
should be able to get rid of the imperative operations, and have instead
of registry of extension - action (ala scons/waf).
What is a registery of
Guido van Rossum guido at python.org writes:
I just found this comment on my blog. People have told me this in
person too, so I believe it is real pain (even if the solution may be
elusive and the suggested solutions may not work). But I don't know
how to improve the world. Is the work on
Tarek Ziadé wrote:
What is a registery of extension exactly ? Distutils let you register your own
commands, you can use through the CLI.
Can you provide more details ?
Sure. Right now, if you want to deal with a new source or a new target,
you need to create a new command or override one.
Georg Brandl wrote:
One thing about CPAN (and Haskell's libraries on hackage) that I think
many people see favorably, even though it's only superficial, is the
more-or-less consistent hierarchical naming for the individual packages
(or the contained modules in Haskell). Compared with that,
On Sun, Nov 8, 2009 at 2:22 PM, David Cournapeau da...@ar.media.kyoto-u.ac.jp
[..]
- if you extend an existing command, you have to take care whether you run
under setuptools or distutils (and soon distribute will make this worse).
No, because unlike setuptools, we want to remove the
On Sat, Nov 07, 2009 at 10:56:24AM -0500, David Lyon wrote:
On Sat, 7 Nov 2009 16:08:46 +0100, Tarek Ziadé ziade.ta...@gmail.com
wrote:
Gosh. I am not your boss, and I am not telling you what to do.
otoh you're the boss of distutils. So you can direct people to
work on certain things to
On Sun, 8 Nov 2009 19:19:44 +, Floris Bruynooghe
floris.bruynoo...@gmail.com wrote:
.. improve the PEP 386
reference implementation for example (I pick that one as I know most
about it from all the PEP proposals currently).
I'm +1 on PEP-386. It makes sense to me.
This is a PEP that
Tarek Ziadé wrote:
On Sun, Nov 8, 2009 at 2:22 PM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp
[..]
- if you extend an existing command, you have to take care whether you run
under setuptools or distutils (and soon distribute will make this worse).
No, because unlike setuptools, we
David Cournapeau wrote:
I don't understand what's there to buy. Several people reported
distutils errors without any backtrace, though a fair shared of those
were caused by our own extensions.
distutils specifically swallows exceptions and formats them for users by
default. After all, it is
Robert Kern wrote:
After all, it is trying to behave like a regular command line program
that interacts with users, not developers. This is easily overridable
for developers who are trying debug problems by setting the
environment variable DISTUTILS_DEBUG=1. This will make distutils just
give
On Sun, Nov 8, 2009 at 10:28 PM, Robert Kern robert.k...@gmail.com wrote:
David Cournapeau wrote:
I don't understand what's there to buy. Several people reported
distutils errors without any backtrace, though a fair shared of those
were caused by our own extensions.
distutils specifically
On Sun, 8 Nov 2009 23:28:42 -0600, Ian Bicking i...@colorstudy.com wrote:
In the tools I've written, I generally give the traceback if the
verbosity is turned up, and in a case like this (an unexpected
exception -- for distutils that's any exception except a few that
distutils defines) I
11/06/2009 08:53 PM, Guido van Rossum:
Python is suffering a lot in the scientific word, because it has not a
CPAN-like repository.
One thing I think is important too:
Perl has helpers that help to distribution-package easily.
Python must have too.
For example, debian packaging what is on
Rakotomandimby Mihamina miham...@gulfsat.mg writes:
For example, debian packaging what is on pypi must be straighforward.
(same for RPM based distribution and other systems)
Packaging for Debian is much more about following the policy, which
deliberately involves human intervention and
David Lyon david.l...@preisshare.net writes:
On Sun, 8 Nov 2009 23:28:42 -0600, Ian Bicking i...@colorstudy.com wrote:
In the tools I've written, I generally give the traceback if the
verbosity is turned up, and in a case like this (an unexpected
exception -- for distutils that's any
Ben Finney wrote:
Rakotomandimby Mihamina miham...@gulfsat.mg writes:
For example, debian packaging what is on pypi must be straighforward.
(same for RPM based distribution and other systems)
Packaging for Debian is much more about following the policy, which
deliberately involves
11/09/2009 09:57 AM, Ben Finney:
For example, debian packaging what is on pypi must be straighforward.
(same for RPM based distribution and other systems)
Packaging for Debian is much more about following the policy, which
deliberately involves human intervention and judgement, and can't very
On Mon, Nov 9, 2009 at 1:09 AM, Ben Finney ben+pyt...@benfinney.id.au wrote:
David Lyon david.l...@preisshare.net writes:
On Sun, 8 Nov 2009 23:28:42 -0600, Ian Bicking i...@colorstudy.com wrote:
In the tools I've written, I generally give the traceback if the
verbosity is turned up, and
Hi Guido,
Guido van Rossum wrote:
On Fri, Nov 6, 2009 at 2:52 PM, David Lyon david.l...@preisshare.net wrote:
So the packages on CPAN are typically of a higher quality, simply
because they've been machine checked. I like that.
Speaking purely on hearsay, I don't believe that. In
Guido van Rossum gu...@python.org writes:
On Fri, Nov 6, 2009 at 2:52 PM, David Lyon david.l...@preisshare.net wrote:
So the packages on CPAN are typically of a higher quality, simply
because they've been machine checked. I like that.
Speaking purely on hearsay, I don't believe that. In
I love how this created a flurry of speculation on what people who say
Python doens't have a CPAN mean. Wouldn't it be easer to *ask* them?
:-)
Just-wondering-ly
--
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
2009/11/7 Kaelin Colclasure kae...@acm.org:
Since I bootstrapped the environment I used to learn Python with
easy_install, I naturally went straight to the easy_install docs to learn
how to give back. I wasn't even aware of this separate thing called
distutils until I read about it in the
On Nov 6, 2009, at 12:53 PM, Guido van Rossum wrote:
I just found this comment on my blog. People have told me this in
person too, so I believe it is real pain (even if the solution may be
elusive and the suggested solutions may not work). But I don't know
how to improve the world. Is the work
On Sat, Nov 7, 2009 at 5:07 AM, David Lyon david.l...@preisshare.net wrote:
On Sat, 7 Nov 2009 02:19:02 +0100, Tarek Ziadé ziade.ta...@gmail.com
wrote:
I unfortunately don't have all the time I wish I had to work on this
more.
We all know that.
It needs somebody new to take on the
2009/11/7 Glyph Lefkowitz gl...@twistedmatrix.com:
One project that would help a lot is just a easy python setup
documentation project that describes, as simply as possible, in large fonts,
how to get a working Python setup that adheres to a few conventions.
[...]
+1 Strong conventions would
David Lyon wrote:
Even if you implement PyPI + PEP 381 + PEP 381 tomorrow I promise
you that you won't be anywhere close to CPAN.
It's a much more serious challenge than perphaps you realise..
I keep reading and I keep hearing you and others saying this, but as
someone who has never used
On Sat, Nov 7, 2009 at 6:04 AM, Jeff Rush j...@taupro.com wrote:
BTW at the recent pyTexas regional conference we had a good group
discussion about packaging, with people offering analysis from the Perl,
Java, Ruby and Haskell communities. It seems each language still only
covers part of the
David Cournapeau schrieb:
Hi Guido,
Guido van Rossum wrote:
On Fri, Nov 6, 2009 at 2:52 PM, David Lyon david.l...@preisshare.net wrote:
So the packages on CPAN are typically of a higher quality, simply
because they've been machine checked. I like that.
Speaking purely on
Tarek Ziadé schrieb:
For the documentation part I am afraid it will be messy for the end
users trying to package apps in Python *until* all PEPs
have made it into Python.
Although, as Ian Bicking says: we could write today some kind of
all-in-one tutorial so end-users can work out without
la, 2009-11-07 kello 00:14 +0200, Alex Grönholm kirjoitti:
[clip: problems in distributing scientific Python packages]
I for one did not understand the problem. What does CPAN have that
PyPI
doesn't?
It is natural for packages (distributions, in distutils terms) to
have
dependencies on
Hi Jeff,
On Sat, 07 Nov 2009 06:04:15 -0600, Jeff Rush j...@taupro.com wrote:
I keep reading and I keep hearing you and others saying this, but as
someone who has never used CPAN, I'm not seeing the large number of
specific implementable tasks that CPAN clearly has and PyPI clearly does
On Sat, 7 Nov 2009 06:53:17 -0600, Brad Allen bradallen...@gmail.com
wrote:
During that conversation Walker mentioned that he thought that Java's
Maven packaging system had been really successful with the idea of
having a metadata file stored outside each package. That made it
easier for the
Hi Tarek,
On Sat, 7 Nov 2009 12:12:44 +0100, Tarek Ziadé ziade.ta...@gmail.com
wrote:
You don't understand at all what is going on I think.
I guess so.
.. it means that we can take
more help from more people (and that includes you of course).
I really do accept that.
What's hard for me
On Sat, Nov 7, 2009 at 3:46 PM, David Lyon david.l...@preisshare.net wrote:
[..]
.. it means that we can take
more help from more people (and that includes you of course).
I really do accept that.
What's hard for me to understand exactly is what you will actually allow
me to do.
Gosh. I
Andreas Jung kirjoitti:
Am 06.11.09 18:53, schrieb Guido van Rossum:
I just found this comment on my blog. People have told me this in
person too, so I believe it is real pain (even if the solution may be
elusive and the suggested solutions may not work). But I don't know
how to improve the
On Sat, Nov 7, 2009 at 3:57 PM, Andreas Jung li...@zopyx.com wrote:
[..]
- supports too much different versioning schemas. Both
schema supported by setuptools and the one proposed
by Tarek in some PEP are totally over-engineered.
A simple and *enforced* versioning schema is what
I
At 03:57 PM 11/7/2009 +0100, Andreas Jung wrote:
- supports too much different versioning schemas. Both
schema supported by setuptools and the one proposed
by Tarek in some PEP are totally over-engineered.
A simple and *enforced* versioning schema is what
I want to see.
- no more
Am 07.11.09 16:37, schrieb Tarek Ziadé:
On Sat, Nov 7, 2009 at 3:57 PM, Andreas Jung li...@zopyx.com wrote:
[..]
- supports too much different versioning schemas. Both
schema supported by setuptools and the one proposed
by Tarek in some PEP are totally over-engineered.
A simple
On Sat, 7 Nov 2009 16:08:46 +0100, Tarek Ziadé ziade.ta...@gmail.com
wrote:
Gosh. I am not your boss, and I am not telling you what to do.
otoh you're the boss of distutils. So you can direct people to
work on certain things to help you along. That would have kept
me much quieter with work.
On 03:56 pm, li...@zopyx.com wrote:
Am 07.11.09 16:37, schrieb Tarek Ziad�:
On Sat, Nov 7, 2009 at 3:57 PM, Andreas Jung li...@zopyx.com wrote:
[..]
- supports too much different versioning schemas. Both
schema supported by setuptools and the one proposed
by Tarek in some PEP are totally
1 - 100 of 106 matches
Mail list logo
