<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 13, 2015 at 9:12 AM, Monty Taylor <span dir="ltr"><<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 04/12/2015 06:43 PM, Robert Collins wrote:<br>
> Right now we do something that upstream pip considers wrong: we make<br>
> our requirements.txt be our install_requires.<br>
><br>
> Upstream there are two separate concepts.<br>
><br>
> install_requirements, which are meant to document what *must* be<br>
> installed to import the package, and should encode any mandatory<br>
> version constraints while being as loose as otherwise possible. E.g.<br>
> if package A depends on package B version 1.5 or above, it should say<br>
> B>=1.5 in A's install_requires. They should not specify maximum<br>
> versions except when that is known to be a problem: they shouldn't<br>
> borrow trouble.<br>
><br>
> deploy requirements - requirements.txt - which are meant to be *local<br>
> to a deployment*, and are commonly expected to specify very narrow (or<br>
> even exact fit) versions.<br></span></blockquote><div><br></div><div>That sounds, to me, very similar to a discussion we had a few weeks ago in the context of our stable branches.</div><div><br></div><div>In that context, we have two competing requirements. One requirement is that our CI system wants a very tightly pinned requirements, as do downstream CI systems and deployers that want to test and deploy exact known-tested versions of things. On the other hand, downstream distributors (including OS packagers) need to balance OpenStack's version requirements with version requirements from all the other packages in their distribution; the tighter the requirements we list are, the harder it is for the requirements to work with the requirements of other packages in the distribution.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
<br>
</span>tl;dr - I'm mostly in support of what you're saying - but I'm going to<br>
bludgeon it some.<br>
<br>
To be either fair or unfair, depending on how you look at it - some<br>
people upstream consider those two to be a pattern, but it is not<br>
encoded anywhere except in hidden lore that is shared between secret<br>
people. Upstream's tools have bumpkiss for support for this, and if we<br>
hadn't drawn a line in the sand encoding SOME behavior there would still<br>
be nothing.<br>
<br>
Nor, btw, is it the right split. It optimizes for the wrong thing.<br>
<br>
rust gets it wright. There is a Cargo.toml and a Cargo.lock, which are<br>
understood by the tooling in a manner similar to what you have<br>
described, and it is not just understood but DOCUMENTED that an<br>
_application_ should ship with a Cargo.lock and a _library_ should not.<br></blockquote><div><br></div><div>This sounds similar to a solution that was proposed for the stable branches: a <a href="http://requirements.in">requirements.in</a> with mandatory version constraints while being as loose as otherwise possible, which is used to generate a requirements.txt which has the "local to deployment" exact versions that are used in our CI. The details of the proposal are in <a href="https://review.openstack.org/#/c/161047/">https://review.openstack.org/#/c/161047/</a> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Without the library/application distinction, the effort in<br>
differentiating is misplaced, I believe - because it's libraries that<br>
need flexible depends - and applications where the specific set of<br>
depends that were tested in CI become important to consumers.<br>
<span class=""><br>
> What pbr, which nearly if not all OpenStack projects use, does, is to<br>
> map the contents of requirements.txt into install_requires. And then<br>
> we use the same requirements.txt in our CI to control whats deployed<br>
> in our test environment[*]. and there we often have tight constraints<br>
> like seen here -<br>
> <a href="http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt#n63" target="_blank">http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt#n63</a><br>
<br>
</span>That is, btw, because that's what the overwhelming majority of consumers<br>
assume those files mean. I take "overwhelming majority" from the days<br>
when we had files but did not process them automatically and everyone<br>
was confused.<br>
<span class=""><br>
> I'd like to align our patterns with those of upstream, so that we're<br>
> not fighting our tooling so much.<br>
<br>
</span>Ok. I mean, they don't have a better answer, but if it makes "python"<br>
hate us less, sweet.<br>
<span class=""><br>
> Concretely, I think we need to:<br>
>  - teach pbr to read in install_requires from setup.cfg, not requirements.txt<br>
>  - when there are requirements in setup.cfg, stop reading requirements.txt<br>
>  - separate out the global intall_requirements from the global CI<br>
> requirements, and update our syncing code to be aware of this<br>
><br>
> Then, setup.cfg contains more open requirements suitable for being on<br>
> PyPI, requirements.txt is the local CI set we know works - and can be<br>
> much more restrictive as needed.<br>
><br>
> Thoughts? If there's broad apathy-or-agreement I can turn this into a<br>
> spec for fine coverage of ramifications and corner cases.<br>
<br>
</span>I'm concerned that it adds a layer of difference that is confusing to<br>
people for the sole benefit of pleasing someone else's pedantic worldview.<br>
<br>
I'm also concerned that dstufft is actively wanting to move towards a<br>
world where the build tooling is not needed or used as part of the<br>
install pipeline (metadata 2.0) -- so I'm concerned that we're aligning<br>
with a pattern that isn't very robust and isn't supported by tooling<br>
directly and that we're going to need to change understood usage<br>
patterns across a large developer based to chase something that _still_<br>
isn't going to be "how people do it"<br>
<br>
I'm concerned that "how people do it" is a myth not worth chasing.<br>
<br>
I'm not _opposed_ to making this richer and more useful for people. I<br>
just don't know what's broken currently for us.<br></blockquote><div><br></div><div>To be clear, I don't mean to suggest that the solution proposed in <a href="https://review.openstack.org/#/c/161047/">https://review.openstack.org/#/c/161047/</a> is necessarily the correct solution to this problem - but I do think that it is illustrative of at last one thing that's currently broken for us.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><font color="#888888"><br>
Monty<br>
</font></span><div class=""><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>