[tc][requirements][horizon] Broken gates due to the new setuptools and pyScss package

Akihiro Motoki amotoki at gmail.com
Tue Mar 17 04:26:31 UTC 2020


Hi,

I agree with JP that this thread covers multiple topics.
I would like to use this thread to focus on the original topic of the
horizon gate breakage
and cover other topic on further discussions in separate threads.

TLDR;  the workaround to fork pyScss and django-pyscss is a good compromise
as a short-term solution. it allows us to explore alternatives without
blocking other patches.

On Mon, Mar 16, 2020 at 9:27 PM Mohammed Naser <mnaser at vexxhost.com> wrote:
>
> Would a more sustainable workaround of switching the pyscss code to
> something that uses libsass-python:
>
> https://pypi.org/project/django-libsass/
>
> That seems like an alternative and it means maintaining _far_ less code..
>

Using python-libsass sounds reasonable as libsass is a mature C/C++ SASS engine
and python-libsass provides the python bindings for it.

I see two libsass support for Django: django-libsass (mnaser mentioned
above) and
django-sass-processor. I am not sure which is better at the moment.

[1] https://pypi.org/project/django-libsass/
[2] https://pypi.org/project/django-sass-processor/

On the other hand, they are not drop-in-replacement, so the migration
may take time.
We have the gate breakage right now, so I think the workaround to fork
pyScss and
django-pyscss is a good compromise as a short-term solution. it allows
us to explore
alternatives without blocking other patches.

On Mon, Mar 16, 2020 at 6:27 PM Lajos Katona <katonalala at gmail.com> wrote:
>
> Hi,
> I would like to just add my cent to the question of ownership of these forked repos:
> I am on the side to have opendev ownership over them as that give long(er) term stability,
> even now when we have serious shortages in design. But consider the situation when
> e0ne leave the community, we have to do the fork again and move these repos under
> opendev umbrella.

I discussed it with e0ne when he forked these repositories.
We don't want to depend on them. We are forking these repos but it is
just to catch up
the recent changes in setuptools and to give us time to explore alternatives.
We don't plan to maintain features in pyscss itself in the forked repository.
This is a short-time workaround and IMHO it is not a good idea to
create and retire
repositories under OpenStack governance in a short term. If we decide
to continue to
use these libraries, then it is time to host these forked repositories
in OpenStack world.

Thanks,
Akihiro



More information about the openstack-discuss mailing list