<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 21, 2015 at 5:03 AM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 01/20/2015 08:15 PM, Robert Collins wrote:<br>
> On 21 January 2015 at 10:21, Clark Boylan <<a href="mailto:cboylan@sapwetik.org">cboylan@sapwetik.org</a>> wrote:<br>
> ...<br>
>> This ml thread came up in the TC meeting today and I am responding here<br>
>> to catch the thread up with the meeting. The soft update option is the<br>
>> suggested fix for non openstack projects that want to have most of their<br>
>> requirements managed by global requirements.<br>
>><br>
>> For the project structure reform opening things up we should consider<br>
>> loosening the criteria to get on the list and make it primarily based on<br>
>> technical criteria such as py3k support, license compatibility, upstream<br>
>> support/activity, and so on (basically the current criteria with less of<br>
>> a focus on where the project comes from if it is otherwise healthy).<br>
>> Then individual projects would choose the subset they need to depend on.<br>
>> This model should be viable with different domains as well if we go that<br>
>> route.<br>
>><br>
>> The following is not from the TC meeting but addressing other portions<br>
>> of this conversation:<br>
>><br>
>> At least one concern with this option is that as the number of total<br>
>> requirements goes up is the difficulty in debugging installation<br>
>> conflicts becomes more difficult too. I have suggested that we could<br>
>> write tools to help with this. Install bisection based on pip logs for<br>
>> example, but these tools are still theoretical so I may be<br>
>> overestimating their usefulness.<br>
>><br>
>> To address the community scaling aspect I think you push a lot of work<br>
>> back on deployers/users if we don't curate requirements for anything<br>
>> that ends up tagged as "production ready" (or whatever the equivalent<br>
>> tag becomes). Essentially we are saying "this doesn't scale for us so<br>
>> now you deal with the fallout. Have fun", which isn't very friendly to<br>
>> people consuming the software. We already have an absurd number of<br>
>> requirements and management of them has appeared to scale. I don't<br>
>> foresee my workload going up if we open up the list as suggested.<br>
><br>
> Perhaps I missed something, but the initial request wasn't about<br>
> random packages, it was about other stackforge clients - these are<br>
> things in the ecosystem! I'm glad we have technical solutions, but it<br>
> just seems odd to me that adding them would ever have been<br>
> controversial.<br>
<br>
</div></div>Well, I think Clark and I have different opinions of how much of a pain<br>
unwinding the requirements are, and how long these tend to leave the<br>
gate broken. I am happy to also put it in a "somebody elses problem<br>
field" for resolving the issues. :)<br>
<br>
Honestly, I think we're actually at a different point, where we need to<br>
stop assuming that the sane way to deal with python is to install it<br>
into system libraries, and just put every service in a venv and get rid<br>
of global requirements entirely. Global requirements was a scaling fix<br>
for getting to 10 coexisting projects. I don't think it actually works<br>
well with 50 ecosystem projects. Which is why I proposed the domains<br>
solution instead.<br>
<span class=""><br></span></blockquote><div><br></div><div>++ using per service virtual environments would help us avoid a whole class of nasty issues. On the flip side doing this makes things harder for distros to find a set of non-conflicting dependencies etc.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> On the pip solver side, joe gordon was working on a thing to install a<br>
> fixed set of packages by bypassing the pip resolver... not sure how<br>
> thats progressing.<br>
<br>
</span>I think if we are talking seriously about bypassing the pip resolver, we<br>
should step back and think about that fact. Because now we're producting<br>
a custom installation process that will produce an answer for us, which<br>
is completely different than any answer that anyone else is getting for<br>
how to get a coherent system.<br></blockquote><div><br></div><div>Fully agreed, I am looking into avoiding pips dependency solver for stable branches only right now. But using per service venvs would be even better.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="im HOEnZb"><br>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
</span><div class="HOEnZb"><div class="h5">__________________________________________________________________________<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>