Migrate away from pipenv
Closed this issue · 2 comments
pipenv is struggling with dealing PEP 508 OS specifics when generating the lock file, and in turn causes problems downstream (by implicating that enum34 is a dependency of numba and llvmlite).
While the issue can be worked around (and we presently do) by pinning numba and llvmlite to older versions, this isn't an ideal solution.
Also in part, due to other issues involving pipenv on windows development, other platforms may work better.
Some alternatives for managing dependencies include
- venv (python3 -m venv)
- virtualenv
- conda
- poetry
The first two options are fairly equivalent, the 3rd option will require conda in the path; but we can leverage conda-env from it. Poetry has some other nice features as it assumes you're working on a pip installable package, and will build the distribution on your behalf (and upload it to pypi).
I'm of the mindset to mandate a conda environment from the makefile and go from there.
Anyone have any other thoughts?
My vote is for conda as well.
(apologies for the pipenv issues, you should try the master branch which will likely resolve the issue in question)
One point on poetry:
Poetry has some other nice features as it assumes you're working on a pip installable package, and will build the distribution on your behalf (and upload it to pypi).
pipenv install -e .
And you can always just add a [scripts] section to your Pipfile which contains the following:
[scripts]
upload = 'twine upload dist/*'Happy to help troubleshoot this bug if you still experience it, I've spent considerable time reworking how markers are fed through the resolution process, specifically with regard to handling local & editable packages which are always fully pre-resolved