<div dir="ltr">Hi,<div><br></div><div>Thanks for the clear way forward Akihiro, I hope that this helps us.</div><div><br></div><div>Lajos</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Akihiro Motoki <<a href="mailto:amotoki@gmail.com">amotoki@gmail.com</a>> ezt írta (időpont: 2020. márc. 17., K, 5:31):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
I agree with JP that this thread covers multiple topics.<br>
I would like to use this thread to focus on the original topic of the<br>
horizon gate breakage<br>
and cover other topic on further discussions in separate threads.<br>
<br>
TLDR;  the workaround to fork pyScss and django-pyscss is a good compromise<br>
as a short-term solution. it allows us to explore alternatives without<br>
blocking other patches.<br>
<br>
On Mon, Mar 16, 2020 at 9:27 PM Mohammed Naser <<a href="mailto:mnaser@vexxhost.com" target="_blank">mnaser@vexxhost.com</a>> wrote:<br>
><br>
> Would a more sustainable workaround of switching the pyscss code to<br>
> something that uses libsass-python:<br>
><br>
> <a href="https://pypi.org/project/django-libsass/" rel="noreferrer" target="_blank">https://pypi.org/project/django-libsass/</a><br>
><br>
> That seems like an alternative and it means maintaining _far_ less code..<br>
><br>
<br>
Using python-libsass sounds reasonable as libsass is a mature C/C++ SASS engine<br>
and python-libsass provides the python bindings for it.<br>
<br>
I see two libsass support for Django: django-libsass (mnaser mentioned<br>
above) and<br>
django-sass-processor. I am not sure which is better at the moment.<br>
<br>
[1] <a href="https://pypi.org/project/django-libsass/" rel="noreferrer" target="_blank">https://pypi.org/project/django-libsass/</a><br>
[2] <a href="https://pypi.org/project/django-sass-processor/" rel="noreferrer" target="_blank">https://pypi.org/project/django-sass-processor/</a><br>
<br>
On the other hand, they are not drop-in-replacement, so the migration<br>
may take time.<br>
We have the gate breakage right now, so I think the workaround to fork<br>
pyScss and<br>
django-pyscss is a good compromise as a short-term solution. it allows<br>
us to explore<br>
alternatives without blocking other patches.<br>
<br>
On Mon, Mar 16, 2020 at 6:27 PM Lajos Katona <<a href="mailto:katonalala@gmail.com" target="_blank">katonalala@gmail.com</a>> wrote:<br>
><br>
> Hi,<br>
> I would like to just add my cent to the question of ownership of these forked repos:<br>
> I am on the side to have opendev ownership over them as that give long(er) term stability,<br>
> even now when we have serious shortages in design. But consider the situation when<br>
> e0ne leave the community, we have to do the fork again and move these repos under<br>
> opendev umbrella.<br>
<br>
I discussed it with e0ne when he forked these repositories.<br>
We don't want to depend on them. We are forking these repos but it is<br>
just to catch up<br>
the recent changes in setuptools and to give us time to explore alternatives.<br>
We don't plan to maintain features in pyscss itself in the forked repository.<br>
This is a short-time workaround and IMHO it is not a good idea to<br>
create and retire<br>
repositories under OpenStack governance in a short term. If we decide<br>
to continue to<br>
use these libraries, then it is time to host these forked repositories<br>
in OpenStack world.<br>
<br>
Thanks,<br>
Akihiro<br>
<br>
</blockquote></div>