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)

Most upvoted comments

Adhering to a strict versioning scheme is certainly the most sensible approach. @randallpittman Until Mathworks changes its distribution, you can use the following worakaround. Sorry I didn’t think of it sooner.

1. Copy all files and sub-directories from the directory `matlabroot/extern/engines/python` to a location of your choice.

2. Open the file `setup.py` in an editor and change the following lines:
   
   * Point the `_bin_dir` variable in the `_generate_arch_file` function to the `bin` folder in the Matlab root directory. The `_bin_dir` string must end with a path separator.
   * Change the version string in the `setup` call to be compatible with semantic versioning.

3. Install the matlab engine:  `python .\setup.py build install`

@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 to import matlab.engine it cannot find libmx.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 to matlabroot/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 of setup.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

randallpittman on Aug 4, 2021

@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.

randallpittman on Dec 24, 2020

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”.

randallpittman on Dec 21, 2020

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.

randallpittman on Nov 30, 2020