enum34 tripping up Python 3.7.3 #1122
Comments
|
I have the same problem installing a dependency using poetry add texat --path TexAT/analysis/texatTraceback: The thing is, this doesn't seem to be anything to do with Poetry. The blame here lies with |
|
@agoose77 I have this problem as well. Can you explain a bit more what it means "... I've just removed it manually for now"? Thx. |
|
I just removed it using pip, which is obviously not ideal :p |
|
Thanks @agoose77 . So this means that the poetry machine is not available right? I have a use case where one of my projects, a library, is hosted on Github and I want to install it into some other project. I would like to do it with The workaround I am using currently is to build the library locally and then install it via |
|
|
pipdeptree shows that enum34 is:
But, when it's uninstalled, poetry reinstalls it. Can't figure out why (yet). Where the hec is enum34 coming from? It's not packaged in poetry itself (at least not in the So, poetry 1.x (poetry-develop) will not encounter this bug in the development process, AFAICT, at least on py ^3.6 but maybe it's present in earlier py-ver builds/CI? |
So, with poetry 0.12.x on py3.6, this is not something introduced by poetry itself (nor is it introduced by miniconda3 when it is used to create a base py3.6 env). |
It was introduced by rasterio 1.x But, even so, the The https://github.com/mapbox/rasterio/blob/master/requirements.txt#L6 has an explicit dependency on enum34 for py<3.4 - is something messed up in this syntax (or how it is used by setup.py)? https://stackoverflow.com/questions/19559247/requirements-txt-depending-on-python-version Or maybe something to do with On the poetry side, parsing the environment-markers is the feature that should control this According to PEP-0508, the restriction example they give looks like Translating that to rasterio/enum looks almost identical to what is already there (only a whitespace and single->double quote change). |
|
The following "hack" does not solve the problem from the poetry perspective by using an explicit dependency to exclude enum34 like so It still installs the enum34. Even a version incompatibility did not avoid installing enum34 because rasterio has no version restraints on it and poetry installed version 1.1.6 anyway (which is the really weird bit). With enum34 at version > 1.0, things seemed to work, but with enum34 at 1.0, the bug is reproduced |
|
Sanity check: OK, good. |
|
Having the same issue with enum34... Is there still no fix for this? I'm currently using poetry 1.0.0b3 on MacOS 10.15 My workaround is the following:
It's a very suboptimal solution because if you want to build a Docker container you have to make sure to copy the Here is an example of my very weird hack to overcome this issue during Docker build: If anyone has a better solution please post! |
This doesn't seem to work; I can't replicate it in any way, shape or form. Seems like Poetry fails to interpret setuptools If this project is added to I'm encountering this issue with There's definitely something wrong with poetry's dependency resolution here. |
|
Hey @Granitosaurus did you uninstall Worst case go to the lock file after you did a |
I did: No luck resolving this other than manually editing lock file which is really awkward and kinda defeats the whole purpose of |
|
@Granitosaurus I dont know.. I am annoyed by this myself. I have the problem with tensorflow, but adding to my project toml and uninstalling enum34 / deleting the env works for me. I am using python 3.7.4 though |
|
@Granitosaurus This is not on Poetry's end. If you look at the PyPI API here: https://pypi.org/pypi/couchbase/json. The Every reported case in this issue is a variation of this. For instance, it's the same thing for In each case it should be reported upstream. |
|
@sdispater |
|
@sdispater Would it be possible to at least orchestrate the installation order of packages? Let's say I have a package like Something like: [tool.poetry.dependencies]
python = "^3.7"
numpy = "^1.17.3"
matplotlib = "^3.1.1"
couchbase = {version = "^2.5.9", order = "-1"}Or simply execute the installation per package consecutively as specified in |
|
Really poetry should have some sort of resolution order and priority - this will be an endless cat and mouse game. You either:
I should be able to specify explictly that this dependency should be ignored. |
|
It would be great if poetry had a way to get those broken packages under control. If I depend on a package which includes Should fix the issue. Right now the python version is ignored. I guess it's on purpose, so there could be additional flag, to enforce or overwrite this dependency And this should pin the correct marker / version regardless of the rest of the dependency tree. It could be named WDYT? It might also be useful in other cases, e.g. if we want to force our own fork of a particular dependency, without changing the dependent library. |
|
I'd generally be heavily in favor of
Chasing upsream just doesn't seem to be sustainable as a single strategy imho. |
|
When I curl So - unsure what the issue is. I've installed this version (using pip3) with python 3.6 in the past without issues, as well. There are embedded quotes, but I'm not sure if that is an issue. LMK what I'm missing here and I'll see if we can fix it. |
|
The version specifier was only just added in the latest release (December): |
|
Echoing #1122 (comment): Interesting, we had already noticed that at least some implementations of Environmental Markers from PEP508, require double rather than single quotes around marker_expr strings - the "enum34; python_version<'3.5'" marker was there since enum34 was added - we simply changed the single to double quotes and that has seemed to satisfy PyPi and the remaining PEP508 implementations. It looks like perhaps whatever Poetry uses for PEP508 is the same. It does look like this sort of quoting is indicated in the examples, though I can't see it clearly in the grammar here: https://www.python.org/dev/peps/pep-0508/#grammar ... In fact, in the 'tests' at https://www.python.org/dev/peps/pep-0508/#id27 there is a line as follows:
Has our change in couchbase==2.5.9 resolved the issue with Poetry, at least? |
|
I was able to fix this by adding |
|
@mickeykkim thanks a lot, your workaround works! 🎉 |
This isn't working for me because a package is conservatively being interpreted as having an enum34 1.1.9 requirement This is definitely an enum34 issue, but seeing as it's a backport for older versions of enum -- can't there be a way that poetry interprets the requirement as met if we're running python34+? Pipenv finally had a release and it seems like this might be what they are doing. Alternatively, I think the only real workaround is to not include the package in the pyproject.toml and then pip install (which kind of defeats the purposes of a package manager) |
|
I've suddenly starting to experience this. |
|
Okay. I was able to fix this by upgrading |
Fixes #7050 ### Motivation To prevent installing enum34 on systems where it is not needed, declare the dependency with environment markers. Installing certain versions of enum34 on systems where it is not needed at all, might result in compile time issues. This is the recommended approach discussed here: python-poetry/poetry#1122 ### Modifications * `setup.py`: use environment markers for enum34 instead of custom logic that is not preserved in pypi metadata for the wheel
Fixes #7050 ### Motivation To prevent installing enum34 on systems where it is not needed, declare the dependency with environment markers. Installing certain versions of enum34 on systems where it is not needed at all, might result in compile time issues. This is the recommended approach discussed here: python-poetry/poetry#1122 ### Modifications * `setup.py`: use environment markers for enum34 instead of custom logic that is not preserved in pypi metadata for the wheel (cherry picked from commit edf0944)
Fixes apache#7050 ### Motivation To prevent installing enum34 on systems where it is not needed, declare the dependency with environment markers. Installing certain versions of enum34 on systems where it is not needed at all, might result in compile time issues. This is the recommended approach discussed here: python-poetry/poetry#1122 ### Modifications * `setup.py`: use environment markers for enum34 instead of custom logic that is not preserved in pypi metadata for the wheel
enum34 appears to be a potential source of problems when installed in environments using Python 3.4 or later [0, 1]. Apparently enum34 1.1.8 was able to avoid these issues, but a regression was introduced in 1.1.9 and is still present in the most recent release [2]. This commit loosens the requirement on enum34 so that it is only installed if Python 3.3 or older is used. This particular solution requires setuptools v36.2 or newer [3]. If older versions of setuptools need to be supported, then the requirements can be put into an extras_require clause [4, 5]. [0]: python-poetry/poetry#1122 [1]: iterative/dvc#1995 [2]: https://web.archive.org/web/20200621215937/https://bitbucket.org/stoneleaf/enum34/issues/31/make-the-install-a-noop-on-python36 [3]: https://setuptools.readthedocs.io/en/latest/history.html#v36-2-0 [4]: robshakir/pyangbind#232 (comment) [5]: https://gitlab.com/pycqa/flake8/-/merge_requests/191/diffs
|
Seems to be solved on enum34 sight. That's why I'm closing this issue. |
## Use OpenVINO from pip * Install OpenVINO by pip * Update OpenVINO to latest 2021.3 version * Use `enum34==1.1.8` to fix "AttributeError: module 'enum' has no attribute 'IntFlag'" (python-poetry/poetry#1122 (comment)) test run: https://github.com/dkurt/deepvariant/actions/runs/755874669 PiperOrigin-RevId: 369485495
Fixes #7050 ### Motivation To prevent installing enum34 on systems where it is not needed, declare the dependency with environment markers. Installing certain versions of enum34 on systems where it is not needed at all, might result in compile time issues. This is the recommended approach discussed here: python-poetry/poetry#1122 ### Modifications * `setup.py`: use environment markers for enum34 instead of custom logic that is not preserved in pypi metadata for the wheel
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
-vvvoption).enum34has long caused packaging problems, for example:tox,netmiko,numba,tensorflow.(Gosh, even a compatibility library solely for it exists.)
My issue is with
luigi. Relevant history I can find is:Now I have two machines, with not-identical but out-of-my-control settings:
and machine 2:
On the first machine, I can create a project which explicitly installs
enum34(asluigidoes) and then a second one which depends on it:Running on the first machine:
...no problem. Running on the second machine:
Two different machines, two different Python versions, and two different
poetryversions - don't know where to start.The text was updated successfully, but these errors were encountered: