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
-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 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
just too much work.
-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, the former I can see
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 versions.cfg, or you run your own
-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 implement; you just make available
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.
Tres has
-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 see happening
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 as
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 be
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 just make
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 agreed on.
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
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 more specific
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
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
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.
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 that
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
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 benefit
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 A
-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
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
not see it
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:
This is an important point. As I see it the KGS is a Zope-only
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 zope.foo 1.3.x, then it should
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 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
package it
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
if someone installs one of our packages
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
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,
On Mon, Mar 16, 2009 at 10:24 AM, Martijn Faassen
faas...@startifact.com 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
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 here is
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! :)
:-)
The most widely open requirement
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
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 less an
2009/3/16 Martijn Faassen faas...@startifact.com:
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
On Mar 16, 2009, at 12:05 PM, Dan Korostelev wrote:
2009/3/16 Martijn Faassen faas...@startifact.com:
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
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
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 specifying open
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 restrictions on
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 version. In other words
41 matches
Mail list logo