+1
For deployment, I have a script that create a svn tag from trunk, run
buildout and create tarball of the resulting buildout. On the
production, another script will unpack the tarball and rerun buildout
but this time with -N -o and since the eggs already in the tarball,
it's very quick and it ju
+1
This is potentially useful for Heroku or Google Apps, or anything that
requires all your files to exist inside the build area after build
time from where it creates the blob that is actually pushed to all the
slaves.
On Mon, May 13, 2013 at 4:26 PM, Daniel Holth wrote:
> Sounds like a nice fe
Sounds like a nice feature. I like having copies of everything (and
nothing extra) for each deployment.
On Mon, May 13, 2013 at 3:08 PM, Jim Fulton wrote:
> Problem
> ===
>
> For (stage and production) deployment purposed, we, ZC, use RPMs.
> It's considered good hygene to produce source RPMs
Problem
===
For (stage and production) deployment purposed, we, ZC, use RPMs.
It's considered good hygene to produce source RPMs as well as binary
RPMS. This led me to create zc.sourcerelease, which automates
creation of self-contained source tar balls, that, among other
benefits, provide inp
On Mon, May 13, 2013 at 10:16 AM, Ian Cordasco
wrote:
> On Mon, May 13, 2013 at 10:12 AM, Reinout van Rees
> wrote:
>> On 13-05-13 15:57, Ian Cordasco wrote:
>>>
>>> If I release a library dependent upon a particular API in one version
>>> of a dependency and before I release my next version I n
see here in the docs
http://www.pip-installer.org/en/latest/logic.html#requirements-file-format
On Mon, May 13, 2013 at 9:57 AM, Daniel Holth wrote:
> You can include many of pip's command line arguments in its
> requirements files; try putting --index-url right there, seems to work
> on the tip
You can include many of pip's command line arguments in its
requirements files; try putting --index-url right there, seems to work
on the tip:
--index-url=someindex
... other requirements
On Mon, May 13, 2013 at 12:48 PM, John Anderson wrote:
>
>
>
> On Mon, May 13, 2013 at 6:08 AM, Marcus Smith
On Mon, May 13, 2013 at 6:08 AM, Marcus Smith wrote:
>
> If I have a shared dependency between 2 packages but they have pinned
>> different versions of a 3rd package, is there a way to override this?
>>
>> Most of the time when people pin a version they are doing it because they
>> have tested up
On Mon, May 13, 2013 at 10:03 AM, Daniel Holth wrote:
> It is very difficult to guarantee that your library will never work
> with any newer version of some other library, but if you can (e.g.
> python-dateutil, versions >= 2 being exclusively Python 3 compatible),
> a < or <= qualifier may be app
On Mon, May 13, 2013 at 10:12 AM, Reinout van Rees wrote:
> On 13-05-13 15:57, Ian Cordasco wrote:
>>
>> If I release a library dependent upon a particular API in one version
>> of a dependency and before I release my next version I notice plans to
>> break the existing API, why shouldn't I pin th
On 13-05-13 15:57, Ian Cordasco wrote:
If I release a library dependent upon a particular API in one version
of a dependency and before I release my next version I notice plans to
break the existing API, why shouldn't I pin the version to protect
users (or at least provide a maximum version) from
It is very difficult to guarantee that your library will never work
with any newer version of some other library, but if you can (e.g.
python-dateutil, versions >= 2 being exclusively Python 3 compatible),
a < or <= qualifier may be appropriate. != is a good one if you know
an exact version of some
On Mon, May 13, 2013 at 7:53 AM, Jim Fulton wrote:
> Gaaa. Libraries shouldn't pin versions (although min and max
> versions with reasonable ranges is fine).
As a library author, I'm intrigued. Why shouldn't I or others pin
versions? Let's provide a situation where it may be necessary (in my
opin
> If I have a shared dependency between 2 packages but they have pinned
> different versions of a 3rd package, is there a way to override this?
>
> Most of the time when people pin a version they are doing it because they
> have tested up to that version, but it doesn't always mean they don't work
On Mon, May 13, 2013 at 3:54 AM, John Anderson wrote:
> If I have a shared dependency between 2 packages but they have pinned
> different versions of a 3rd package, is there a way to override this?
>
> Most of the time when people pin a version they are doing it because they
> have tested up to th
If I have a shared dependency between 2 packages but they have pinned
different versions of a 3rd package, is there a way to override this?
Most of the time when people pin a version they are doing it because they
have tested up to that version, but it doesn't always mean they don't work
with a la
16 matches
Mail list logo
