-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lennart Regebro wrote:
> There has been two related proposals afaik. Tareks talk about plugins,
> and mine where I said I would like the default behavior to be:
>
> 1. The file list is gotten from a specification in setup.py.
> 2. If no such specific
On Wed, Apr 8, 2009 at 12:06 PM, Lennart Regebro wrote:
> There has been two related proposals afaik. Tareks talk about plugins,
> and mine where I said I would like the default behavior to be:
>
> 1. The file list is gotten from a specification in setup.py.
> 2. If no such specification, the file
Meta discussions are generally a complete waste of time. This is the
only thing I intend to say on the issue.
On Wed, Apr 8, 2009 at 11:44, Paul Moore wrote:
> As a bystander, what *I* care most about is that Python ends up with a
> single approach to creating and distributing extensions. What co
On Wed, Apr 8, 2009 at 11:48 AM, Paul Moore wrote:
> 2009/4/8 Paul Moore :
>> As a bystander, what *I* care most about is that Python ends up with a
>> single approach to creating and distributing extensions. What concerns
>> me most about this whole discussion, is that it seems like no-one is
>>
2009/4/8 Paul Moore :
> As a bystander, what *I* care most about is that Python ends up with a
> single approach to creating and distributing extensions. What concerns
> me most about this whole discussion, is that it seems like no-one is
> attempting to compromise, and participants are pulling fur
2009/4/8 Ben Finney :
> David Cournapeau writes:
>
>> Ok. Looks like you feel insulted for some reasons to keep insulting
>> me back. Since I can't make my point clearly, and nobody in this
>> discussion seems to care anyway, I will leave the discussion.
>
> I hope you can reconsider (but certainl
On Wed, Apr 8, 2009 at 09:40, Marius Gedminas wrote:
> Are we talking about the current design (which doesn't include
> everything), or about some proposed change?
Proposed change, of course. That the current situation is broken is
well established. Nobody is defending it.
--
Lennart Regebro: P
On Tue, Apr 07, 2009 at 07:27:29PM +0200, Lennart Regebro wrote:
> On Tue, Apr 7, 2009 at 19:12, Marius Gedminas wrote:
> > Consider a different use case: my friend's friend Alice does not like
> > svn. She uses git-svn to get a local git repository containing a copy
> > of the subversion code.
David Cournapeau writes:
> Ok. Looks like you feel insulted for some reasons to keep insulting
> me back. Since I can't make my point clearly, and nobody in this
> discussion seems to care anyway, I will leave the discussion.
I hope you can reconsider (but certainly a little time away from the
d
Lennart Regebro wrote:
> On Wed, Apr 8, 2009 at 06:04, David Cournapeau
> wrote:
>
>> It does if the underlying implementation is not shared correctly between
>> all the tools.
>>
>
> Since we are discussing what the underlying implementation to be
> shared by all tools should be, that's a
On Wed, Apr 8, 2009 at 06:04, David Cournapeau
wrote:
> It does if the underlying implementation is not shared correctly between
> all the tools.
Since we are discussing what the underlying implementation to be
shared by all tools should be, that's a rather pointless comment.
> Now, how can I us
Lennart Regebro wrote:
> Nobody has anywhere in this discussion suggested anything that in any
> shape, form or way prevents any sort of other usage.
>
It does if the underlying implementation is not shared correctly between
all the tools. Having plugins to support VCS is ok, as long as the dat
On Wed, Apr 8, 2009 at 04:58, David Cournapeau
wrote:
> Why those assumptions on what people can do. That's exactly what's wrong
> with distutils for me, all those untold assumptions, which are
> 'obviously' correct. As I said previously, including built documentation
> is something I use MANIFEST
David Cournapeau writes:
> Tres Seaver wrote:
> > There are three classes of files here:
> >
> > - "source" files, which should be under version control, and
> > included (by default) in the sdist.
> >
> > - "derived" files, which should *not* be under version control,
> > but which might (in cer
Tres Seaver wrote:
> David Cournapeau 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 :)
>
> There are three classes of files here:
>
> - "source" files
On Apr 7, 2009, at 11:12 AM, Marius Gedminas wrote:
Consider a different use case: my friend's friend Alice does not
like svn. She uses git-svn to get a local git repository
containing a copy of the subversion code. She then uses the usual
'python setup.py sdist' build process. It produc
On Tue, Apr 7, 2009 at 19:12, Marius Gedminas wrote:
> Consider a different use case: my friend's friend Alice does not like
> svn. She uses git-svn to get a local git repository containing a copy
> of the subversion code. She then uses the usual 'python setup.py sdist'
> build process. It prod
On Tue, Apr 07, 2009 at 08:12:39PM +0300, Marius Gedminas wrote:
> On Tue, Apr 07, 2009 at 07:20:11AM +0200, Lennart Regebro wrote:
> > OK, here is a usecase. I have a directoy with a module, foo.bar. I
> > have also in that directory saved a project file from my IDE, because
> > naturally I save a
On Tue, Apr 07, 2009 at 07:20:11AM +0200, Lennart Regebro wrote:
> OK, here is a usecase. I have a directoy with a module, foo.bar. I
> have also in that directory saved a project file from my IDE, because
> naturally I save a project file into the directory of every project I
> have. But since tha
Let me just throw in that my uses cases for all of my projects so far
are:
1. There should not be any file included in the distribution that
isn't included under VCS.
1.a. *except* that there is this one Python source code file named
_version.py which is autogenerated from VCS and is no
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Cournapeau 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 :)
There are three classes of files here:
-
On Tue, Apr 7, 2009 at 15:02, Floris Bruynooghe
wrote:
> The VCS is an external piece of software outside of Python and the
> distutils. There also isn't just one VCS, there's many of them and
> all of them are on different release schedules which differ from
> Python's and/or distutils's release
On Tue, Apr 7, 2009 at 3:02 PM, Floris Bruynooghe
wrote:
>> Where in this is there a "lower level"?
>
> Number 1 could be the simple lower level, a list of files (I'm not
> saying this is a good choice, I haven't studied all the issues good
> enough). That way the tool you use to consume setup.py
On Tue, Apr 07, 2009 at 10:09:33AM +0200, Lennart Regebro wrote:
> On Tue, Apr 7, 2009 at 09:40, David Cournapeau
> wrote:
> > Lennart Regebro wrote:
> >>
> >> "Lower system"? What would that be? This is about if we should support
> >> getting a file list from the VCS or not to determine what file
On Tue, Apr 07, 2009 at 02:41:07PM +0900, David Cournapeau wrote:
> Lennart Regebro wrote:
> > On Tue, Apr 7, 2009 at 07:20, David Cournapeau
> > 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 some
Lennart Regebro wrote:
>
> Possibly. I can't say we are arguing though. You are just saying that
> you don't agree, but you still come with no arguments for your
> standpoint or against mine.
Ok.
David
___
Distutils-SIG maillist - Distutils-SIG@pytho
On Tue, Apr 7, 2009 at 09:40, David Cournapeau
wrote:
> Lennart Regebro wrote:
>>
>> "Lower system"? What would that be? This is about if we should support
>> getting a file list from the VCS or not to determine what files should
>> go in a sdist.
>
> We can argue all day long
Possibly. I can't s
Lennart Regebro wrote:
>
> "Lower system"? What would that be? This is about if we should support
> getting a file list from the VCS or not to determine what files should
> go in a sdist.
We can argue all day long - but since there is a disagreement, there is
only two issues: either someone decide
On Mon, Apr 06, 2009 at 09:55:47AM -0400, P.J. Eby wrote:
> 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:
>> >
On Tue, Apr 7, 2009 at 07:41, David Cournapeau
wrote:
> I am not saying that it should not be possible - but that it should be
> built on top of a lower system which we can all agree upon. Then, you
> can use your tool to depend on the VCS to feed this lower system, and I
> can reuse this lower sy
Lennart Regebro wrote:
> On Tue, Apr 7, 2009 at 07:20, David Cournapeau
> 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 hav
On Tue, Apr 7, 2009 at 07:20, David Cournapeau
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
each file separately. Which is
On Tue, Apr 7, 2009 at 07:36, Robert Kern 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
> of telling the s
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 2009-04-07 00:20, Lennart Regebro wrote:
On Tue, Apr 7, 2009 at 06:17, David Cournapeau
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 g
On Tue, Apr 7, 2009 at 06:17, David Cournapeau
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 sdist/build-process,
David Cournapeau 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 distinction.
--
\
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 :)
Moving away from "using VCS is good" vs "using VCS is not good", maybe
we should focus on the workflows to support. The
David Cournapeau 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 including non-VCS con
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 [3]
Tres Seaver wrote:
>
> It is often true for *lots* of release management strategies that the
> release managers have to do extra work to create a release tarball
> (e.g., re-run autogen, etc., or flex / bison, etc.), and that the
> released tarball does not include enough information to rebuild it
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 genera
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tarek Ziadé wrote:
> On Mon, Apr 6, 2009 at 4:04 PM, P.J. Eby 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 MANI
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tarek Ziadé wrote:
> 2009/4/6 P.J. Eby :
>> 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 MANIF
-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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tarek Ziadé wrote:
> On Mon, Apr 6, 2009 at 9:30 AM, Lennart Regebro wrote:
>> On Mon, Apr 6, 2009 at 09:23, Tarek Ziadé wrote:
I don't understand a large part of this discussion, but it seems to me
that the expected and reasonable way of d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ben Finney wrote:
> Lennart Regebro writes:
>
>> On Mon, Apr 6, 2009 at 08:02, 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*.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tarek Ziadé wrote:
> On Mon, Apr 6, 2009 at 2:51 AM, P.J. Eby 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 create a dis
On Mon, Apr 6, 2009 at 19:28, Bob Ippolito 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 understand it.
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
On Mon, Apr 6, 2009 at 10:11 AM, zooko 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
> http://pypi.python.org/pypi/setu
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
Re
At 05:32 PM 4/6/2009 +0200, Tarek Ziadé wrote:
2009/4/6 P.J. Eby :
> At 04:43 PM 4/6/2009 +0200, Lennart Regebro wrote:
>>
>> On Mon, Apr 6, 2009 at 16:04, P.J. Eby wrote:
>> > I don't understand why you're so anxious to deprecate something without
>> > first understanding what it's for.
>>
>> I
On Mon, Apr 6, 2009 at 17:46, Tarek Ziadé 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 bdist_*,
> etc..
2009/4/6 Lennart Regebro :
> 2009/4/6 P.J. Eby :
>> 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 eas
2009/4/6 P.J. Eby :
> 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. :)
> I agree with yo
On Mon, Apr 6, 2009 at 5:19 PM, P.J. Eby 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 discussed in the Summ
2009/4/6 P.J. Eby :
> At 04:43 PM 4/6/2009 +0200, Lennart Regebro wrote:
>>
>> On Mon, Apr 6, 2009 at 16:04, P.J. Eby 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
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
> platfor
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 mo
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 tar
At 04:43 PM 4/6/2009 +0200, Lennart Regebro wrote:
On Mon, Apr 6, 2009 at 16:04, P.J. Eby 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
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 :
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
On Mon, Apr 6, 2009 at 16:04, P.J. Eby 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 Regebro: Pythonista, Barista
On Mon, Apr 6, 2009 at 16:17, Leonardo Santagada 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.
That is not a bre
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.
On Mon, Apr 6, 2009 at 4:12 PM, P.J. Eby wrote:
> At 03:53 PM 4/6/2009 +0200, Tarek Ziadé wrote:
>>
>> 2009/4/6 P.J. Eby :
>> > Have you ever *used* plain distutils for a significant project? I
>> > invented
>> > the source control feature in setuptools because I was constantly ending
>> > up
>>
On Mon, Apr 6, 2009 at 4:04 PM, P.J. Eby 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 least) is
On Apr 6, 2009, at 8:31 AM, Lennart Regebro wrote:
2009/4/6 David Cournapeau :
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 .hg,.svn or whatever it
At 03:53 PM 4/6/2009 +0200, Tarek Ziadé wrote:
2009/4/6 P.J. Eby :
> 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
At 03:40 PM 4/6/2009 +0200, Tarek Ziadé wrote:
On Mon, Apr 6, 2009 at 3:40 PM, P.J. Eby 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.
>>
>> This me
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 t
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
>>
2009/4/6 P.J. Eby :
> 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 MANIFEST.in. It's not going t
At 10:14 AM 4/6/2009 +0200, Tarek Ziadé wrote:
On Mon, Apr 6, 2009 at 10:05 AM, Lennart Regebro wrote:
> On Mon, Apr 6, 2009 at 09:51, Tarek Ziadé 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 wor
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. S
On Mon, Apr 6, 2009 at 3:40 PM, P.J. Eby 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.
>>
>> This means the glob-style pattern will need to have an e
2009/4/6 P.J. Eby
> 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 some no
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 some non-installed data are inside a directory th
2009/4/6 David Cournapeau :
> 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.
http://regebro.wordpress.com/
+33 661 58 14 64
_
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
2009/4/6 David Cournapeau :
> 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
On Mon, Apr 6, 2009 at 11:10, Tarek Ziadé wrote:
> On Mon, Apr 6, 2009 at 11:03 AM, Lennart Regebro wrote:
>> On Mon, Apr 6, 2009 at 10:14, Tarek Ziadé 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
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 soft
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
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 (
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 f
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 bre
On Mon, Apr 6, 2009 at 11:03 AM, Lennart Regebro wrote:
> On Mon, Apr 6, 2009 at 10:14, Tarek Ziadé 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?
>
because in 1.2 you don't w
2009/4/6 David Cournapeau :
> To be consistent, it
> needs to be included in distutils, so when the VCS format changes, it
> breaks - you can't update it easily because it is in the stdlib.
Sure, if the plugin can't use a stable API then it should not be
included in the stdlib.
> And if the sourc
On Mon, Apr 6, 2009 at 10:14, Tarek Ziadé 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... this is not a
> long
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:05 AM, Lennart Regebro wrote:
> On Mon, Apr 6, 2009 at 09:51, Tarek Ziadé 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
2009/4/6 David Cournapeau :
> It is practical on the short term, but a pain in the long term. The
> single most problematic aspect of distutils (and the tools above it) is
> all this magic which works in some simple cases, and breaks in other,
> without any way to circumvent it.
So make a way to c
On Mon, Apr 6, 2009 at 09:51, Tarek Ziadé 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 should be forced
to
Lennart Regebro wrote:
>
> It's a practical default.
>
It is practical on the short term, but a pain in the long term. The
single most problematic aspect of distutils (and the tools above it) is
all this magic which works in some simple cases, and breaks in other,
without any way to circumvent
On Mon, Apr 6, 2009 at 9:30 AM, Lennart Regebro wrote:
> On Mon, Apr 6, 2009 at 09:23, Tarek Ziadé 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 fi
On Mon, Apr 6, 2009 at 09:23, Tarek Ziadé 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 the VCS.
On Mon, Apr 6, 2009 at 08:40, Ben Finney wrote:
> Lennart Regebro writes:
>
>> On Mon, Apr 6, 2009 at 08:02, 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*.
>>
>> What's
2009/4/6 Lennart Regebro :
> On Mon, Apr 6, 2009 at 08:02, 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*.
>
> What's the difference?
>
>
> Personally, I agree that if there is a
1 - 100 of 122 matches
Mail list logo
