David Cournapeau da...@ar.media.kyoto-u.ac.jp writes:
Ben Finney wrote:
Okay, but that's a far cry from saying that it “doesn't make
sense” to use the VCS inventory.
Not that a far cry: python packaging tools are the only systems that
I know of which does this. For example, in autotools,
On Mon, Apr 6, 2009 at 08:02, Ben Finney ben+pyt...@benfinney.id.au wrote:
I'm not advocating using the VCS to *generate the tarball*. I'm
talking about using the VCS to *determine what files to put in the
tarball*.
What's the difference?
Personally, I agree that if there is a VCS, and no
Ben Finney wrote:
I'm not advocating using the VCS to *generate the tarball*. I'm
talking about using the VCS to *determine what files to put in the
tarball*.
Currently, using the vcs plugin does include everything as far as I
know. So what do you have in mind ?
David
Tarek Ziadé wrote:
what do you mean ? (beside the feature that is decribed in the ticket
- which enables adding files recursively)
I mean something more fine-grained than package_data, and more explicit.
So that we can separate tests, documentation, etc... as every linux
packaging expects.
On Mon, Apr 6, 2009 at 08:40, Ben Finney ben+pyt...@benfinney.id.au wrote:
Lennart Regebro rege...@gmail.com writes:
On Mon, Apr 6, 2009 at 08:02, Ben Finney ben+pyt...@benfinney.id.au wrote:
I'm not advocating using the VCS to *generate the tarball*. I'm
talking about using the VCS to
On Mon, Apr 6, 2009 at 09:23, Tarek Ziadé ziade.ta...@gmail.com wrote:
I don't understand a large part of this discussion, but it seems to me
that the expected and reasonable way of determening what files to
include would be to:
1. Specify files in setup.py
2. Use the files that is a part of
On Mon, Apr 6, 2009 at 9:30 AM, Lennart Regebro rege...@gmail.com wrote:
On Mon, Apr 6, 2009 at 09:23, Tarek Ziadé ziade.ta...@gmail.com wrote:
I don't understand a large part of this discussion, but it seems to me
that the expected and reasonable way of determening what files to
include would
On Mon, Apr 6, 2009 at 09:51, Tarek Ziadé ziade.ta...@gmail.com wrote:
So part of your file list is declared implicitely in your (D)VCS and
part explicitely in your setup.
I don't see how that would work. Reasonably, the VCS is a fallback of
nothing is declared in setup.py. I don't see why you
On Mon, Apr 6, 2009 at 10:05 AM, Lennart Regebro rege...@gmail.com wrote:
On Mon, Apr 6, 2009 at 09:51, Tarek Ziadé ziade.ta...@gmail.com wrote:
So part of your file list is declared implicitely in your (D)VCS and
part explicitely in your setup.
I don't see how that would work. Reasonably,
Lennart Regebro wrote:
Yes. And can you point out what in my suggestion is not simple, and
what is magic, and what is not circumventable?
- Not simple: you need a plugin for each VCS. To be consistent, it
needs to be included in distutils, so when the VCS format changes, it
breaks - you
On Mon, Apr 6, 2009 at 10:14, Tarek Ziadé ziade.ta...@gmail.com wrote:
Ok so, in version 1.2 of your package, you use the implicit way (VCS based)
then you introduce a new file, that forces your to be explicit in 1.3
Why?
so you use setup.py
then in 1.4 you're back in an implicit list...
David Cournapeau wrote:
No other distribution mechanism that I know of uses magic to detect
which files to distribute. Neither debian tools, nor rpm tools, nor
autotools. Not being explicit about files for distribution is a terrible
idea; a packaging tool should be explicit, to avoid as much as
On Mon, Apr 6, 2009 at 11:10, Tarek Ziadé ziade.ta...@gmail.com wrote:
On Mon, Apr 6, 2009 at 11:03 AM, Lennart Regebro rege...@gmail.com wrote:
On Mon, Apr 6, 2009 at 10:14, Tarek Ziadé ziade.ta...@gmail.com wrote:
Ok so, in version 1.2 of your package, you use the implicit way (VCS based)
2009/4/6 David Cournapeau da...@ar.media.kyoto-u.ac.jp:
Lennart Regebro wrote:
Sure, if the plugin can't use a stable API then it should not be
included in the stdlib.
I was not talking about the plugin stability, but about the situation
where the VCS detection is broken. As it has
rpm(build) is a build tool, doens't deal with source distribution (but
it generates srpms
from the build sources).
There's a mild autodetection in rpmbuild when used in a restricted environment:
it detects installed but unpackaged files under $RPM_BUILD_ROOT.
It fails apart when used to build
On Sun, Apr 05, 2009 at 07:51:41PM -0400, P.J. Eby wrote:
At 11:24 PM 4/5/2009 +0300, Marius Gedminas wrote:
On Sun, Apr 05, 2009 at 06:45:45PM +0200, Tarek Ziadé wrote:
After some discussions with people at Pycon, we think that the
MANIFEST template should be removed.
+1 for fixing the
2009/4/6 David Cournapeau da...@ar.media.kyoto-u.ac.jp:
python setup.py sdist # put everything under svn into the tarball
cd dist uncompress tarball python setup.py sdist # the tarball is
not the same
Why not?
--
Lennart Regebro: Pythonista, Barista, Notsotrista.
I know it might look sooo web 0.1 but has anyone thought to put
the whole sdist stuff under a flow chart (as well the distutils stuffs)?
Much of this discussion it would be easier in some way.
About the vcs magics.
Some vcs systems do not have special directories under the
source structures
Lennart Regebro wrote:
Sure, if the plugin can't use a stable API then it should not be
included in the stdlib.
I was not talking about the plugin stability, but about the situation
where the VCS detection is broken. As it has happened with setuptools
very recently.
How does it break?
On Mon, Apr 06, 2009 at 02:12:58AM +0200, Tarek Ziadé wrote:
Right now most people in the community uses reST for their
long_description metadata. It looks good in PyPI since it's displayed
in HTML.
But if the reST is broken, it does not look right. (which happen regularly)
I'd like to
Lennart Regebro wrote:
Well, because the tarball will include the files in the VCS. But sure,
if you in the tarball case add files in the directory that are not in
the VCS, that would be included too. Maybe that's a problem, I don't
know. I can't see the problem myself, but maybe somebody
On Mon, Apr 6, 2009 at 11:03 AM, Lennart Regebro rege...@gmail.com wrote:
On Mon, Apr 6, 2009 at 10:14, Tarek Ziadé ziade.ta...@gmail.com wrote:
Ok so, in version 1.2 of your package, you use the implicit way (VCS based)
then you introduce a new file, that forces your to be explicit in 1.3
2009/4/6 P.J. Eby p...@telecommunity.com
At 03:11 AM 4/6/2009 +0200, Tarek Ziadé wrote:
Right,
that would require something else, maybe a new one, ignored by the
install command
and using the glob-style pattern.
This means the glob-style pattern will need to have an exclude mechanism
if
At 03:02 PM 4/6/2009 +0900, David Cournapeau wrote:
Ben Finney wrote:
I'm not advocating using the VCS to *generate the tarball*. I'm
talking about using the VCS to *determine what files to put in the
tarball*.
Currently, using the vcs plugin does include everything as far as I
know. So
At 10:14 AM 4/6/2009 +0200, Tarek Ziadé wrote:
On Mon, Apr 6, 2009 at 10:05 AM, Lennart Regebro rege...@gmail.com wrote:
On Mon, Apr 6, 2009 at 09:51, Tarek Ziadé ziade.ta...@gmail.com wrote:
So part of your file list is declared implicitely in your (D)VCS and
part explicitely in your setup.
2009/4/6 P.J. Eby p...@telecommunity.com:
Have you ever *used* plain distutils for a significant project? I invented
the source control feature in setuptools because I was constantly ending up
with files missing from my sdists, due to forgetting to add some sort of
glob pattern to
At 12:25 PM 4/6/2009 +0300, Marius Gedminas wrote:
On Sun, Apr 05, 2009 at 07:51:41PM -0400, P.J. Eby wrote:
At 11:24 PM 4/5/2009 +0300, Marius Gedminas wrote:
On Sun, Apr 05, 2009 at 06:45:45PM +0200, Tarek Ziadé wrote:
After some discussions with people at Pycon, we think that the
At 08:08 PM 4/6/2009 +0900, David Cournapeau wrote:
My use case is very simple, and yet very common. If you have your
sources in a VCS system, say svn:
python setup.py sdist # put everything under svn into the tarball
cd dist uncompress tarball python setup.py sdist # the tarball is
not the
At 03:40 PM 4/6/2009 +0200, Tarek Ziadé wrote:
On Mon, Apr 6, 2009 at 3:40 PM, P.J. Eby p...@telecommunity.com wrote:
At 03:11 AM 4/6/2009 +0200, Tarek Ziadé wrote:
Right,
that would require something else, maybe a new one, ignored by the
install command
and using the glob-style pattern.
At 03:53 PM 4/6/2009 +0200, Tarek Ziadé wrote:
2009/4/6 P.J. Eby p...@telecommunity.com:
Have you ever *used* plain distutils for a significant project? I invented
the source control feature in setuptools because I was constantly ending up
with files missing from my sdists, due to forgetting
On Apr 6, 2009, at 8:31 AM, Lennart Regebro wrote:
2009/4/6 David Cournapeau da...@ar.media.kyoto-u.ac.jp:
python setup.py sdist # put everything under svn into the tarball
cd dist uncompress tarball python setup.py sdist # the
tarball is
not the same
Why not?
It will be missing the
On Mon, Apr 6, 2009 at 4:04 PM, P.J. Eby p...@telecommunity.com wrote:
We already have this... it's called MANIFEST.in.
hum, ok let's deprecate what package_data provides then, (the ability
to define a list
of files without a MANIFEST.in template)
MANIFEST.in (under setuptools at
On Mon, Apr 6, 2009 at 4:12 PM, P.J. Eby p...@telecommunity.com wrote:
At 03:53 PM 4/6/2009 +0200, Tarek Ziadé wrote:
2009/4/6 P.J. Eby p...@telecommunity.com:
Have you ever *used* plain distutils for a significant project? I
invented
the source control feature in setuptools because I
P.J. Eby wrote:
At 08:08 PM 4/6/2009 +0900, David Cournapeau wrote:
My use case is very simple, and yet very common. If you have your
sources in a VCS system, say svn:
python setup.py sdist # put everything under svn into the tarball
cd dist uncompress tarball python setup.py sdist # the
On Mon, Apr 6, 2009 at 16:17, Leonardo Santagada santag...@gmail.com wrote:
It will be missing the .hg,.svn or whatever it used to generate the file
list.
Why would that break anything? As it's not a checkout, it will not use
these files to generate the file list, but instead include all files.
On Mon, Apr 6, 2009 at 16:04, P.J. Eby p...@telecommunity.com wrote:
I don't understand why you're so anxious to deprecate something without
first understanding what it's for.
If nobody understands it, that is in itself reason to replace it with
something people understand.
--
Lennart
At 11:17 AM 4/6/2009 -0300, Leonardo Santagada wrote:
On Apr 6, 2009, at 8:31 AM, Lennart Regebro wrote:
2009/4/6 David Cournapeau da...@ar.media.kyoto-u.ac.jp:
python setup.py sdist # put everything under svn into the tarball
cd dist uncompress tarball python setup.py sdist # the
tarball
At 04:43 PM 4/6/2009 +0200, Lennart Regebro wrote:
On Mon, Apr 6, 2009 at 16:04, P.J. Eby p...@telecommunity.com wrote:
I don't understand why you're so anxious to deprecate something without
first understanding what it's for.
If nobody understands it, that is in itself reason to replace it
At 11:18 PM 4/6/2009 +0900, David Cournapeau wrote:
P.J. Eby wrote:
At 08:08 PM 4/6/2009 +0900, David Cournapeau wrote:
My use case is very simple, and yet very common. If you have your
sources in a VCS system, say svn:
python setup.py sdist # put everything under svn into the tarball
cd
At 04:23 PM 4/6/2009 +0200, Tarek Ziadé wrote:
Because we have too many ways to handle this problem right now.
Then why add another one? Because AFAICT you won't be able to
support the full range of existing distutils use cases without
something approximating MANIFEST.in. And what is the
P.J. Eby wrote:
That means creating an installation manifest format that is 100%
explicit, and then having tools (including distutils/setuptools
commands, and plugins for other build systems) that can generate that
manifest, as well as tools to install files according to different
platforms'
2009/4/6 P.J. Eby p...@telecommunity.com:
At 04:43 PM 4/6/2009 +0200, Lennart Regebro wrote:
On Mon, Apr 6, 2009 at 16:04, P.J. Eby p...@telecommunity.com wrote:
I don't understand why you're so anxious to deprecate something without
first understanding what it's for.
If nobody
On Mon, Apr 6, 2009 at 5:19 PM, P.J. Eby p...@telecommunity.com wrote:
I agree with you. But I 100% disagree with Tarek that the way to get there
is by refactoring the distutils. The distutils are stable (i.e., dead and
obsolete) and need to be *replaced*, not refactored.
No it's not. As
2009/4/6 P.J. Eby p...@telecommunity.com:
I mean understanding the use cases and how distutils features are used in
the field.
This is of course true. But quite likely, the only one who does that
is you. So it's up to you to document it so others can make solutions
that are easy to understand.
2009/4/6 Lennart Regebro rege...@gmail.com:
2009/4/6 P.J. Eby p...@telecommunity.com:
I mean understanding the use cases and how distutils features are used in
the field.
This is of course true. But quite likely, the only one who does that
is you. So it's up to you to document it so others
On Mon, Apr 6, 2009 at 17:46, Tarek Ziadé ziade.ta...@gmail.com wrote:
That was not exactly the conclusion of the summit. The idea is to make
distutils
a light, reference library, on wich third party libraries could implements
OS-dependant features and so on. So part of the plan is to remove
At 05:32 PM 4/6/2009 +0200, Tarek Ziadé wrote:
2009/4/6 P.J. Eby p...@telecommunity.com:
At 04:43 PM 4/6/2009 +0200, Lennart Regebro wrote:
On Mon, Apr 6, 2009 at 16:04, P.J. Eby p...@telecommunity.com wrote:
I don't understand why you're so anxious to deprecate something without
first
Why not? Aren't there setuptools plugins available for the common
DVCSes?
http://pypi.python.org/pypi/setuptools_hg
http://pypi.python.org/pypi/setuptools_darcs
http://pypi.python.org/pypi/setuptools_bzr
http://pypi.python.org/pypi/setuptools-git
http://pypi.python.org/pypi/setuptools_mtn
On Mon, Apr 6, 2009 at 10:11 AM, zooko zo...@zooko.com wrote:
Why not? Aren't there setuptools plugins available for the common DVCSes?
http://pypi.python.org/pypi/setuptools_hg
http://pypi.python.org/pypi/setuptools_darcs
http://pypi.python.org/pypi/setuptools_bzr
On Mon, Apr 6, 2009 at 19:28, Bob Ippolito b...@redivi.com wrote:
One particular annoyance is that the svn integration built-in to
setuptools tends to break every time a major release of Subversion
comes out
This is absolutely true, and annoying. Setuptools read the .svn files
directly, as I
One particular annoyance is that the svn integration built-in to
setuptools tends to break every time a major release of Subversion
comes out (e.g. setuptools broke when 1.5 came out, is probably
currently broken with 1.6, etc.). The stable version of setuptools
was broken wrt. svn 1.5 for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tarek Ziadé wrote:
On Mon, Apr 6, 2009 at 2:51 AM, P.J. Eby p...@telecommunity.com wrote:
At 01:49 AM 4/6/2009 +0200, Tarek Ziadé wrote:
So basically, if you get a source distribution out there and work on
it in your own DVCS,
you are unable to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ben Finney wrote:
Lennart Regebro rege...@gmail.com writes:
On Mon, Apr 6, 2009 at 08:02, Ben Finney ben+pyt...@benfinney.id.au wrote:
I'm not advocating using the VCS to *generate the tarball*. I'm
talking about using the VCS to *determine what
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tarek Ziadé wrote:
On Mon, Apr 6, 2009 at 9:30 AM, Lennart Regebro rege...@gmail.com wrote:
On Mon, Apr 6, 2009 at 09:23, Tarek Ziadé ziade.ta...@gmail.com wrote:
I don't understand a large part of this discussion, but it seems to me
that the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Cournapeau wrote:
Lennart Regebro wrote:
Well, because the tarball will include the files in the VCS. But sure,
if you in the tarball case add files in the directory that are not in
the VCS, that would be included too. Maybe that's a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tarek Ziadé wrote:
2009/4/6 P.J. Eby p...@telecommunity.com:
At 06:45 PM 4/5/2009 +0200, Tarek Ziadé wrote:
Hello
After some discussions with people at Pycon, we think that the
MANIFEST template should be removed.
I would like to deprecate
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tarek Ziadé wrote:
On Mon, Apr 6, 2009 at 4:04 PM, P.J. Eby p...@telecommunity.com wrote:
We already have this... it's called MANIFEST.in.
hum, ok let's deprecate what package_data provides then, (the ability
to define a list
of files without a
Tres Seaver wrote:
In *any* case I know of: including non-VCS-controleld files in an sdist
is an anti-usecase for me.
A simple example: including sphinx-generated documentation. If including
non-VCS controled stuff is an anti-case, then why having sdist at all ?
Any half decent VCS can
On Apr 6, 2009, at 3:03 AM, Lennart Regebro wrote:
Could we in this discussion, instead of making fuzzy general
statements explain exactly what the problems are?
So far, the setuptools behavior has worked fine for me on both
numerous small projects (e.g. pyutil [1], zfec [2], pycryptopp
I am working on a tool we call dino which uses sqlalchemy 0.5.3
Its an update of a previous version (called dino) which uses sqlalchemy
0.4.4.
For reasons I don't have to go into, I would like to have both tools
installed on the same host,
with almost no changes to the existing tool. Thus
David Cournapeau da...@ar.media.kyoto-u.ac.jp writes:
Tres Seaver wrote:
In *any* case I know of: including non-VCS-controleld files in an
sdist is an anti-usecase for me.
A simple example: including sphinx-generated documentation.
That's a good counter-point to Tres's point, true.
If
At 05:04 PM 4/6/2009 -0700, Nicholas Veeser wrote:
I am working on a tool we call dino which uses sqlalchemy 0.5.3
Its an update of a previous version (called dino) which uses sqlalchemy 0.4.4.
For reasons I don't have to go into, I would like to have both tools
installed on the same host,
David Cournapeau da...@ar.media.kyoto-u.ac.jp writes:
Ben Finney wrote:
An sdist is *not* just a tarball of the source files.
It is if you consider any non-tracked file to be an anti-usecase,
No. In *no case* is an sdist equal to a tarball of the source files.
Please stop blurring the
On Tue, Apr 7, 2009 at 06:17, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
Ben Finney wrote:
An sdist is *not* just a tarball of the source files.
It is if you consider any non-tracked file to be an anti-usecase, which
is what I was answering to :)
Except for files generated by the
On 2009-04-07 00:20, Lennart Regebro wrote:
On Tue, Apr 7, 2009 at 06:17, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
Ben Finney wrote:
An sdist is *not* just a tarball of the source files.
It is if you consider any non-tracked file to be an anti-usecase, which
is what I was
Lennart Regebro wrote:
Except for files generated by the sdist/build-process, yes. Why would
you want to include files in a distribution that are neither
controlled source files or a result of the sdist/build process?
Depends on what you mean by the build process. I sometimes need to
On Tue, Apr 7, 2009 at 07:36, Robert Kern robert.k...@gmail.com wrote:
Unfortunately, the setup.py file is not always capable of performing all of
the build processes (at least, not easily). One might use a Makefile or
other build tool to build the docs or other assets. So you need a manual way
On Tue, Apr 7, 2009 at 07:20, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
It depends on how you set your wildcard. If you use *.$ext, seems to me
that it would alleviate those cases, or do you mean something else ?
Sure, but now we are getting closer and closer to having to specify
Lennart Regebro wrote:
On Tue, Apr 7, 2009 at 07:20, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
It depends on how you set your wildcard. If you use *.$ext, seems to me
that it would alleviate those cases, or do you mean something else ?
Sure, but now we are getting closer
69 matches
Mail list logo
