search

mozilla-releng / signingscript

Signing script to run in scriptworker.
1 stars 11 forks source link

Use pip-compile-multi #103

Closed rail closed 5 years ago

rail commented 5 years ago

I was playing with pip-compile-multi and signingscript's outdated compiled requirements-prod.txt file and ended up with something like this. Not quite sure if this is what we want, but I'll try. :)

I also added a check in order to verify that the compiled files are on par with their .in equivalents.

@escapewindow what do you think?

escapewindow commented 5 years ago

Hm, pulling from your branch, I was able to run tox for both py36 and py37 without issue on osx. I may be mistaken about my review comments above, though it's also possible we just don't have any dependencies currently that hit it, but we may in the future (or in other *scripts)

rail commented 5 years ago

Hm, pulling from your branch, I was able to run tox for both py36 and py37 without issue on osx. I may be mistaken about my review comments above, though it's also possible we just don't have any dependencies currently that hit it, but we may in the future (or in other *scripts)

Actually I hit an issue, when I tried to run tox on 3.6 with requirements generated with 3.7. A couple of packages (second level deps iirc) were marked as for python<3.7, so they were not in the generated txt files. Regenerating the deps on 3.6 solved the issue. I'm not sure what would be the best approach here, tbh.

coveralls commented 5 years ago

Coverage Status

Coverage remained the same at 100.0% when pulling 07a082a371b24368cbaa58a8ac2345af4f290854 on rail:pip-compile-multi into 6df9f4406d16051be53537973b72fb7df5f39b47 on mozilla-releng:master.

escapewindow commented 5 years ago

Hm, pulling from your branch, I was able to run tox for both py36 and py37 without issue on osx. I may be mistaken about my review comments above, though it's also possible we just don't have any dependencies currently that hit it, but we may in the future (or in other *scripts)

Actually I hit an issue, when I tried to run tox on 3.6 with requirements generated with 3.7. A couple of packages (second level deps iirc) were marked as for python<3.7, so they were not in the generated txt files. Regenerating the deps on 3.6 solved the issue. I'm not sure what would be the best approach here, tbh.

I believe that's because dependencies can be specified for a specific minor version of python, so 3.6 and 3.7 get different lists. And wheels can be compiled for different OS arches, so linux and macosx get different lists. My current thinking about this has been to rely on unpinned deps for testing, and running pinning if and when we have a specific OS/python minor version we're targeting. That would be for deployment or automation, rather than development.

rail commented 5 years ago

Let me remove that line then.