-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Withers wrote:
> Wichert Akkerman wrote:
>> Previously Chris Withers wrote:
>>> Tres Seaver wrote:
>>> KGS the
>>> concept is very easy to implement; you just make available on some URL
>>> a
>>> buildout versions.cfg, or you r
Previously Chris Withers wrote:
> Wichert Akkerman wrote:
> > What we do is: collect the tarballs, serve the resulting directory. I
> > have not seen a need to run a script.
>
> How do you collect the tarballs?
buildout download cache
> How do you serve the resulting directory?
standard apache
Wichert Akkerman wrote:
> Previously Chris Withers wrote:
>> Tres Seaver wrote:
>> KGS the
>> concept is very easy to implement; you just make available on some URL a
>> buildout versions.cfg, or you run your own package index.
> OK, the former I can see happening on an end-user p
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wichert Akkerman wrote:
> Previously Tres Seaver wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Wichert Akkerman wrote:
>>> Previously Chris Withers wrote:
Tres Seaver wrote:
KGS the
concept is very easy to imp
Previously Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Wichert Akkerman wrote:
> > Previously Chris Withers wrote:
> >> Tres Seaver wrote:
> >> KGS the
> >> concept is very easy to implement; you just make available on some URL
> >> a
> >> buildout v
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wichert Akkerman wrote:
> Previously Chris Withers wrote:
>> Tres Seaver wrote:
>> KGS the
>> concept is very easy to implement; you just make available on some URL a
>> buildout versions.cfg, or you run your own package index.
> OK,
Previously Chris Withers wrote:
> Tres Seaver wrote:
> KGS the
> concept is very easy to implement; you just make available on some URL a
> buildout versions.cfg, or you run your own package index.
> >>> OK, the former I can see happening on an end-user project, the latter is
> >>
Tres Seaver wrote:
KGS the
concept is very easy to implement; you just make available on some URL a
buildout versions.cfg, or you run your own package index.
>>> OK, the former I can see happening on an end-user project, the latter is
>>> just too much work.
>
> Not really. Coll
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dieter Maurer wrote:
> Chris Withers wrote at 2009-4-2 20:42 +0100:
>> ...
>>> KGS the
>>> concept is very easy to implement; you just make available on some URL a
>>> buildout versions.cfg, or you run your own package index.
>> OK, the former I can
Chris Withers wrote at 2009-4-2 20:42 +0100:
> ...
>> KGS the
>> concept is very easy to implement; you just make available on some URL a
>> buildout versions.cfg, or you run your own package index.
>
>OK, the former I can see happening on an end-user project, the latter is
>just too much work.
Martijn Faassen wrote:
> KGS is two things:
>
> * KGS the software
>
> * KGS the concept
>
> KGS the concept will have a life outside of the Zope world.
I stand by my predication that even the KGS concept will never make it
beyond Zope...
> KGS the
> concept is very easy to implement; you ju
Roger Ineichen wrote:
> Probably a way to go is to make both concept compatible with
> each other. Which probably means we should be able to ignore
> versions in packages if a KGS concept get used?
> (not sure if this is possible)
NO! This is INSANE!
The version requirements in a package should b
Wichert Akkerman wrote:
>> Are there other Python projects that have to deal with such a huge
>> amount of packages and dependencies? I don't know any similar project.
>> So the solution must come from the Zope world (which does not mean that
>> we participate in the packaging toolchain development
Hey,
Wichert Akkerman wrote:
[snip]
> This is an important point. As I see it the KGS is a Zope-only thing,
> and is just a workaround for the mindless behaviour of setuptools. I do
> not see it gaining acceptance outside of the Zope community, and imho
> effort is better spent on improving the pa
Stephan Richter wrote:
> On Tuesday 17 March 2009, Shane Hathaway wrote:
>> The version requirements in setup.py should specify only API
>> compatibility. They have nothing to do with bug fixes; that's the
>> domain of the KGS. How about an example.
>
> Yes, that's a good summary of what we agre
Hi Wichert
> Betreff: Re: [Zope-dev] setting missing minimum version in setup.py
>
> Previously Andreas Jung wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 23.03.2009 14:26 Uhr, Wichert Akkerman wrote:
> >
> > >
> >
Previously Andreas Jung wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 23.03.2009 14:26 Uhr, Wichert Akkerman wrote:
>
> >
> > This is an important point. As I see it the KGS is a Zope-only thing,
> > and is just a workaround for the mindless behaviour of setuptools. I do
> > no
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 23.03.2009 14:26 Uhr, Wichert Akkerman wrote:
>
> This is an important point. As I see it the KGS is a Zope-only thing,
> and is just a workaround for the mindless behaviour of setuptools. I do
> not see it gaining acceptance outside of the Zope c
Previously Chris Withers wrote:
> Benji York wrote:
> > Lets say that someone adds two bug fixes to zope.foo (call them fix A
> > and fix B) and then does a release. Fix A requires zope.bar >= 1.5 and
> > fix B doesn't. If I want to benefit from fix B in my app (and don't use
> > the feature fix
Roger Ineichen wrote:
> What do you do if version x.y works with d.e.d but not with
> d.e.e (because it's borken) and fixed in d.e.f.
You release x.y.1 which has dependencies on d.e.d, >=d.e.f.
> This is a use case where fixing versions in packages doesn't
> work
Sure it does.
> This is the be
Martijn Faassen wrote:
> x.y.z is a bugfix release. If we do it right, there will be no change in
> the API and only small changes in misbehavior. Therefore it seems far
> less likely to me that a package ends *needing* to depend on a minimum
> version.
I don't agree. If your package hsa bugs
Wichert Akkerman wrote:
> I see no useful different between x.y and x.y.z here. All I want is if
> someone installs one of our packages that package will work as expected.
> If a package will only work with a certain revisions of a dependent
> package it has to state say.
Yes.
> If we do not do t
Roger Ineichen wrote:
> The consequence of fixing versions is to skip backporting.
> There is no way to have both.
Rubbish. Martijn already showed what would need to happen here: the
package specifying the depenedency needs a quick, 3rd point release to
add the backported releases as suitable.
Stephan Richter wrote:
> Updgrading to zope.foo 1.3.x might not be easy for various reasons that I
> think most of us experienced (I know I did). Releasing a new zope.bar version
> might not be possible, if person B does not have access.
If a fix is possible, and someone backports it, a release
Benji York wrote:
> Lets say that someone adds two bug fixes to zope.foo (call them fix A
> and fix B) and then does a release. Fix A requires zope.bar >= 1.5 and
> fix B doesn't. If I want to benefit from fix B in my app (and don't use
> the feature fix A repaired), then I shouldn't be forced to
Martijn Faassen wrote:
> The version requirements in setup.py should always be "open".
>
> The most widely open requirement is this:
>
> zope.foo
>
> but another open requirement is this:
>
> zope.foo >= 1.3
>
> I also don't recall open requirements bringing development to a halt?
>
> I think
On Tuesday 17 March 2009, Shane Hathaway wrote:
> The version requirements in setup.py should specify only API
> compatibility. They have nothing to do with bug fixes; that's the
> domain of the KGS. How about an example.
Yes, that's a good summary of what we agreed on. The more I think about it
Roger Ineichen wrote:
> What do you do if version x.y works with d.e.d but not with
> d.e.e (because it's borken) and fixed in d.e.f.
>
> This means you could use d.e.d or d.e.f. but not d.e.e
>
> What's your solution then?
> Fix the version to d.e.d or d.e.f or skip fixing versions?
The version
Hi Wichert, Steering Group?
> Betreff: Re: [Zope-dev] setting missing minimum version in setup.py
>
> Previously Martijn Faassen wrote:
> > Wichert Akkerman wrote:
> > [snip]
> > > I see no useful different between x.y and x.y.z here. All
> I want is
>
Previously Martijn Faassen wrote:
> Wichert Akkerman wrote:
> [snip]
> > I see no useful different between x.y and x.y.z here. All I want is if
> > someone installs one of our packages that package will work as expected.
> > If a package will only work with a certain revisions of a dependent
> > pa
Wichert Akkerman wrote:
[snip]
> I see no useful different between x.y and x.y.z here. All I want is if
> someone installs one of our packages that package will work as expected.
> If a package will only work with a certain revisions of a dependent
> package it has to state say.
I do see a useful
Previously Jacob Holm wrote:
> Wichert Akkerman wrote:
> > Previously Martijn Faassen wrote:
> >
> >> Hey,
> >>
> >> Stephan Richter wrote:
> >> [snip]
> >>
> >>> There is a compromise I am willing to take. If package zope.bar depends
> >>> on a
> >>> *new feature* or *feature change* in
Wichert Akkerman wrote:
> Previously Martijn Faassen wrote:
>
>> Hey,
>>
>> Stephan Richter wrote:
>> [snip]
>>
>>> There is a compromise I am willing to take. If package zope.bar depends on
>>> a
>>> *new feature* or *feature change* in zope.foo 1.3.x, then it should specify
>>> the ver
Previously Martijn Faassen wrote:
> Hey,
>
> Stephan Richter wrote:
> [snip]
> > There is a compromise I am willing to take. If package zope.bar depends on
> > a
> > *new feature* or *feature change* in zope.foo 1.3.x, then it should specify
> > the version. In other words specifying open restr
Am 16.03.2009 um 16:56 schrieb Martijn Faassen:
> Hey,
>
> Stephan Richter wrote:
> [snip]
>> There is a compromise I am willing to take. If package zope.bar
>> depends on a
>> *new feature* or *feature change* in zope.foo 1.3.x, then it should
>> specify
>> the version. In other words specifyi
Am 16.03.2009 um 15:49 schrieb Benji York:
[...]
> I don't like version requirements in setup.py because they assume too
> much about how people are using the package.
>
> Lets say that someone adds two bug fixes to zope.foo (call them fix A
> and fix B) and then does a release. Fix A requires zop
On Mar 16, 2009, at 12:05 PM, Dan Korostelev wrote:
> 2009/3/16 Martijn Faassen :
>>> There is a compromise I am willing to take. If package zope.bar
>>> depends on a
>>> *new feature* or *feature change* in zope.foo 1.3.x, then it
>>> should specify
>>> the version. In other words specifying
2009/3/16 Martijn Faassen :
>> There is a compromise I am willing to take. If package zope.bar depends on a
>> *new feature* or *feature change* in zope.foo 1.3.x, then it should specify
>> the version. In other words specifying open restrictions on the major version
>> levels is okay, but never on
Hey,
Roger Ineichen wrote:
[snip]
> Even if it's rare, why should we not support that?
>
> The consequence of fixing versions is to skip backporting.
> There is no way to have both. Are you really sure we like to
> skip backporting.
I haven't a clear idea about how often we backport and even les
Hey,
Stephan Richter wrote:
[snip]
> There is a compromise I am willing to take. If package zope.bar depends on a
> *new feature* or *feature change* in zope.foo 1.3.x, then it should specify
> the version. In other words specifying open restrictions on the major version
> levels is okay, but n
Hi
> Betreff: Re: [Zope-dev] setting missing minimum version in setup.py
>
> On Monday 16 March 2009, Martijn Faassen wrote:
> > I'm not sure I agree you here, Stephan. A possible
> disagreement within
> > the steering group, how interesting! :)
>
> :-)
>
On Monday 16 March 2009, Martijn Faassen wrote:
> I'm not sure I agree you here, Stephan. A possible disagreement within
> the steering group, how interesting! :)
:-)
> The most widely open requirement is this:
>
> zope.foo
>
> but another open requirement is this:
>
> zope.foo >= 1.3
Sure, but
On Mon, Mar 16, 2009 at 10:24 AM, Martijn Faassen
wrote:
> Stephan Richter wrote:
>> On Sunday 15 March 2009, Wichert Akkerman wrote:
>>> If the package does not work with an older version of zope.publisher
>>> than imho that version restriction *has* to be in setup.py.
>>
>> And what if I backpor
Stephan Richter wrote:
> On Sunday 15 March 2009, Wichert Akkerman wrote:
>> If the package does not work with an older version of zope.publisher
>> than imho that version restriction *has* to be in setup.py.
>
> And what if I backport the fix?
>
> We have done version specification like this in
44 matches
Mail list logo
