Closed fgrsnau closed 7 years ago
Your work duplicates what I've been preparing for a while.
I have some issues with this PR:
Your work duplicates what I've been preparing for a while.
As far as I know the changes are not public.
Why the reordering? The dependencies were sorted alphabetically.
They were neither sorted alphabetically nor were kept in sync with requirements.txt
.
There is already the setuptools-bower […].
This was the first thing I’ve tried. Unfortunately it did not work correctly. One reason is that dh_virtualenv is called in a fakeroot environment (sure, this is better fixed there) and with setuptools-bower we’re unable to pass additional options (--allow-root
). On the other hand setuptools-bower does not fetch bower itself. I find downloading bower quite useful.
In my opinion the overhead is small, but makes deployment much easier. Additionally the logic can be disabled. If you see problems, I can drop the BowerCommand
.
You should upgrade PIP instead of using the older syntax. The new PIP versions offer this new syntax among other this, such as actual working wheel support, a wheel download cache.
That’s true. Given the fact that we want to use dh_virtualenv for the first Debian packages, this does not pose any problem.
Except for arpreq everything was sorted (case-sensitively) and present in both files.
Why would you want to download bower during with setup.py
?
Ah, I see. I’m more used to locale-aware (or at least case-insensitive) sorting.
I somehow assumed that fetching bower
is the “npm
-way“. I’m not sure. Debian, Ubuntu and Fedora do not have bower
in their repositories. So for me downloading bower
feels a bit like fetching all those JS dependencies. I can be wrong, though.
I'm not against fetching bower at all. But it should not be done by setup.py
.
This is a preparation for #37.