On 04/15/2015 09:50 PM, Robert Collins wrote:
On 16 April 2015 at 11:59, Sean Dague s...@dague.net wrote:
I think the completeness statement here is as follows:
1. For OpenStack to scale to the small end, we need to be able to
overlap services, otherwise you are telling people they
On 2015-04-15 11:06:20 +0200 (+0200), Thierry Carrez wrote:
And the doc is indeed pretty clear. I assumed requirements.txt would
describe... well... requirements. But like Robert said they are meant to
describe specific deployments (should really be have been named
deployment.txt, or at least
On 04/12/2015 06:43 PM, Robert Collins wrote:
Right now we do something that upstream pip considers wrong: we make
our requirements.txt be our install_requires.
Upstream there are two separate concepts.
install_requirements, which are meant to document what *must* be
installed to import
Excerpts from Sean Dague's message of 2015-04-15 06:50:11 -0700:
== End game?
*If* pip install took into account the requirements of everything
already installed like apt or yum does, and resolve accordingly
(including saying that's not possible unless you uninstall or upgrade
X), we'd be
On 14 April 2015 at 21:36, Thierry Carrez thie...@openstack.org wrote:
Robert Collins wrote:
On 13 April 2015 at 22:04, Thierry Carrez thie...@openstack.org wrote:
How does this proposal affect stable branches ? In order to keep the
breakage there under control, we now have stable branches for
On 16 April 2015 at 00:51, Jeremy Stanley fu...@yuggoth.org wrote:
On 2015-04-15 11:06:20 +0200 (+0200), Thierry Carrez wrote:
And the doc is indeed pretty clear. I assumed requirements.txt would
describe... well... requirements. But like Robert said they are meant to
describe specific
On 04/15/2015 06:44 PM, Robert Collins wrote:
On 16 April 2015 at 01:50, Sean Dague s...@dague.net wrote:
On 04/12/2015 06:43 PM, Robert Collins wrote:
Thoughts? If there's broad apathy-or-agreement I can turn this into a
spec for fine coverage of ramifications and corner cases.
I'm
On 15 April 2015 at 09:33, Joe Gordon joe.gord...@gmail.com wrote:
On Tue, Apr 14, 2015 at 2:36 AM, Thierry Carrez thie...@openstack.org
wrote:
Robert Collins wrote:
On 13 April 2015 at 22:04, Thierry Carrez thie...@openstack.org wrote:
How does this proposal affect stable branches ? In
On 15 April 2015 at 09:35, Joe Gordon joe.gord...@gmail.com wrote:
On Sun, Apr 12, 2015 at 6:09 PM, Robert Collins robe...@robertcollins.net
wrote:
On 13 April 2015 at 12:53, Monty Taylor mord...@inaugust.com wrote:
If we pin the stable branches with hard pins of direct and indirect
On 16 April 2015 at 07:58, Clint Byrum cl...@fewbar.com wrote:
Excerpts from Sean Dague's message of 2015-04-15 06:50:11 -0700:
== End game?
*If* pip install took into account the requirements of everything
already installed like apt or yum does, and resolve accordingly
(including saying
On 16 April 2015 at 01:50, Sean Dague s...@dague.net wrote:
On 04/12/2015 06:43 PM, Robert Collins wrote:
Thoughts? If there's broad apathy-or-agreement I can turn this into a
spec for fine coverage of ramifications and corner cases.
I'm definitely happy someone else is diving in on here,
On 16 April 2015 at 11:59, Sean Dague s...@dague.net wrote:
I think the completeness statement here is as follows:
1. For OpenStack to scale to the small end, we need to be able to
overlap services, otherwise you are telling people they basically have
to start with a full rack of hardware to
Joe Gordon wrote:
On Tue, Apr 14, 2015 at 2:55 PM, Chris Dent chd...@redhat.com
mailto:chd...@redhat.com wrote:
On Tue, 14 Apr 2015, Joe Gordon wrote:
deploy requirements - requirements.txt - which are meant to
be *local
to a deployment*, and are
On Apr 15, 2015, at 5:06 AM, Thierry Carrez thie...@openstack.org wrote:
Joe Gordon wrote:
On Tue, Apr 14, 2015 at 2:55 PM, Chris Dent chd...@redhat.com
mailto:chd...@redhat.com wrote:
On Tue, 14 Apr 2015, Joe Gordon wrote:
deploy requirements - requirements.txt - which are
On Sun, Apr 12, 2015 at 3:43 PM, Robert Collins robe...@robertcollins.net
wrote:
Right now we do something that upstream pip considers wrong: we make
our requirements.txt be our install_requires.
Upstream there are two separate concepts.
install_requirements, which are meant to document
On Tue, Apr 14, 2015 at 2:36 AM, Thierry Carrez thie...@openstack.org
wrote:
Robert Collins wrote:
On 13 April 2015 at 22:04, Thierry Carrez thie...@openstack.org wrote:
How does this proposal affect stable branches ? In order to keep the
breakage there under control, we now have stable
On Sun, Apr 12, 2015 at 6:09 PM, Robert Collins robe...@robertcollins.net
wrote:
On 13 April 2015 at 12:53, Monty Taylor mord...@inaugust.com wrote:
What we have in the gate is the thing that produces the artifacts that
someone installing using the pip tool would get. Shipping anything with
On Tue, 14 Apr 2015, Joe Gordon wrote:
Upstream there are two separate concepts.
install_requirements, which are meant to document what *must* be
installed to import the package, and should encode any mandatory
version constraints while being as loose as otherwise possible. E.g.
if package A
On Tue, Apr 14, 2015 at 2:55 PM, Chris Dent chd...@redhat.com wrote:
On Tue, 14 Apr 2015, Joe Gordon wrote:
Upstream there are two separate concepts.
install_requirements, which are meant to document what *must* be
installed to import the package, and should encode any mandatory
version
On 13 April 2015 at 22:04, Thierry Carrez thie...@openstack.org wrote:
This observation led to yet more IRC discussion and eventually
https://etherpad.openstack.org/p/stable-omg-deps
In short, the proposal is that we:
- stop trying to use install_requires to reproduce exactly what
works,
I think what we are trying to do is two separate things.
One is to define the dependencies that packagers use. This would likely
be minimum versions with caps that are known to fail (not assumed).
The second is to define a set of verifiably known working deps. This
would likely need an update
On 13/4/2015, at 3:53, Robert Collins robe...@robertcollins.net wrote:
On 13 April 2015 at 13:09, Robert Collins robe...@robertcollins.net wrote:
On 13 April 2015 at 12:53, Monty Taylor mord...@inaugust.com wrote:
What we have in the gate is the thing that produces the artifacts that
Robert Collins wrote:
On 13 April 2015 at 13:09, Robert Collins robe...@robertcollins.net wrote:
On 13 April 2015 at 12:53, Monty Taylor mord...@inaugust.com wrote:
What we have in the gate is the thing that produces the artifacts that
someone installing using the pip tool would get. Shipping
On 04/12/2015 08:01 PM, James Polley wrote:
On Mon, Apr 13, 2015 at 9:12 AM, Monty Taylor mord...@inaugust.com wrote:
On 04/12/2015 06:43 PM, Robert Collins wrote:
Right now we do something that upstream pip considers wrong: we make
our requirements.txt be our install_requires.
Upstream
On 13 April 2015 at 13:09, Robert Collins robe...@robertcollins.net wrote:
On 13 April 2015 at 12:53, Monty Taylor mord...@inaugust.com wrote:
What we have in the gate is the thing that produces the artifacts that
someone installing using the pip tool would get. Shipping anything with
those
On Mon, Apr 13, 2015 at 9:12 AM, Monty Taylor mord...@inaugust.com wrote:
On 04/12/2015 06:43 PM, Robert Collins wrote:
Right now we do something that upstream pip considers wrong: we make
our requirements.txt be our install_requires.
Upstream there are two separate concepts.
On 13 April 2015 at 12:53, Monty Taylor mord...@inaugust.com wrote:
What we have in the gate is the thing that produces the artifacts that
someone installing using the pip tool would get. Shipping anything with
those artifacts other that a direct communication of what we tested is
just mean
On 13 April 2015 at 12:01, James Polley j...@jamezpolley.com wrote:
That sounds, to me, very similar to a discussion we had a few weeks ago in
the context of our stable branches.
In that context, we have two competing requirements. One requirement is that
our CI system wants a very tightly
On 04/12/2015 06:43 PM, Robert Collins wrote:
Right now we do something that upstream pip considers wrong: we make
our requirements.txt be our install_requires.
Upstream there are two separate concepts.
install_requirements, which are meant to document what *must* be
installed to import
Right now we do something that upstream pip considers wrong: we make
our requirements.txt be our install_requires.
Upstream there are two separate concepts.
install_requirements, which are meant to document what *must* be
installed to import the package, and should encode any mandatory
version
30 matches
Mail list logo
