poetry: Poetry fails when there is something already installed with a bad version
-
[ x] I am on the latest Poetry version.
-
[x ] I have searched the issues of this repo and believe that this is not a duplicate.
-
If an exception occurs when executing a command, I executed it again in debug mode (
-vvv
option). -
OS version and name: Linux bdc34-Latitude-E7450 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24 10:55:24 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
-
Poetry version: Poetry version 1.0.5
-
Link of a Gist with the contents of your pyproject.toml file: not relevant
Issue
When I’m using a venv and I already have a package installed with a version that is not a semver, I get an error.
Expected behavior: Just ignore the package?
I get this error:
$ poetry install -v
Using virtualenv: /home/bdc34/.pyenv/versions/3.6.9/envs/submission-core
[ParseVersionError]
Unable to parse "no-git-or-release-version".
Traceback (most recent call last):
File "/home/bdc34/.pyenv/versions/3.6.9/envs/submission-core/lib/python3.6/site-packages/clikit/console_application.py", line 131, in run
status_code = command.handle(parsed_args, io)
File "/home/bdc34/.pyenv/versions/3.6.9/envs/submission-core/lib/python3.6/site-packages/clikit/api/command/command.py", line 120, in handle
status_code = self._do_handle(args, io)
File "/home/bdc34/.pyenv/versions/3.6.9/envs/submission-core/lib/python3.6/site-packages/clikit/api/command/command.py", line 171, in _do_handle
return getattr(handler, handler_method)(args, io, self)
File "/home/bdc34/.pyenv/versions/3.6.9/envs/submission-core/lib/python3.6/site-packages/cleo/commands/command.py", line 92, in wrap_handle
return self.handle()
File "/home/bdc34/.pyenv/versions/3.6.9/envs/submission-core/lib/python3.6/site-packages/poetry/console/commands/install.py", line 48, in handle
self.io, self.env, self.poetry.package, self.poetry.locker, self.poetry.pool
File "/home/bdc34/.pyenv/versions/3.6.9/envs/submission-core/lib/python3.6/site-packages/poetry/installation/installer.py", line 55, in __init__
installed = self._get_installed()
File "/home/bdc34/.pyenv/versions/3.6.9/envs/submission-core/lib/python3.6/site-packages/poetry/installation/installer.py", line 488, in _get_installed
return InstalledRepository.load(self._env)
File "/home/bdc34/.pyenv/versions/3.6.9/envs/submission-core/lib/python3.6/site-packages/poetry/repositories/installed_repository.py", line 28, in load
package = Package(name, version, version)
File "/home/bdc34/.pyenv/versions/3.6.9/envs/submission-core/lib/python3.6/site-packages/poetry/packages/package.py", line 46, in __init__
self._version = Version.parse(version)
File "/home/bdc34/.pyenv/versions/3.6.9/envs/submission-core/lib/python3.6/site-packages/poetry/semver/version.py", line 206, in parse
raise ParseVersionError('Unable to parse "{}".'.format(text))
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 2
- Comments: 16 (2 by maintainers)
@thaeber
Thanks for the workaround! This does the trick. I use the MATLAB numeric version (9.9.0.1524771) in place of R2020a.EDIT: Step 1 and 2a must not be done, only step 2b and 3 from the original
matlabroot/extern/engines/python
directory. Otherwise when trying toimport matlab.engine
it cannot findlibmx.so
. Rather step 3. must be performed from that dir. I haven’t been able to trace down another way to deal with this, so at the point, you must have r/w access tomatlabroot/extern/engines/python
to build this. But that is necessary irrespective of this particular issue. The workaround of changing the version string at the end ofsetup.py
is completely valid.EDIT 2: MATLAB numeric version can be found at matlabroot/VersionInfo.xml.
EDIT 3: Gist install script:
https://gist.github.com/randallpittman/a542bbfc430f6e0d342a477402ce362d
@sinoroc Sorry, no, it was not in a public forum, more like a form + email exchange. I thought there was a publicly-visible place for submitting issues but I couldn’t find it.
I did open an issue with Mathworks and they were receptive to the PEP 440 info and said the developers will “consider implementing a fix for it in a future release of MATLAB”.
I think in my perfect world there would be a way to have some dep. specs that would be strictly for checking only (installed by some other manner) that would allow arbitrary version strings, or even regex versions.
That said, this particular issue is strictly a problem with parsing the currently installed packages.