PEP 440 version matching of local version identifier clause (e.g. 1.2.3+local) not implemented correctly in solver

[Korijn]

• I am on the latest Poetry version.

• 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: Windows 10, but also in a Linux docker container running Ubuntu 18.04

• Poetry version: 1.0.9

• Link of a Gist with the contents of your pyproject.toml file: https://gist.github.com/Korijn/b88b1605221574f51ee72b75efc03dbe

Issue

In PEP 440, it says the following in the section "Version Matching":

If the specified version identifier is a public version identifier (no local version label), then the local version label of any candidate versions MUST be ignored when matching versions.

I believe this clause is being interpreted incorrectly by Poetry. When running poetry lock on a pyproject.toml file (see the gist linked above) with the folowing lines, poetry incorrectly reports a conflict:

torch = "1.4.0+cpu"
torchvision = "0.5.0+cpu"

   1: conflict: torchvision (0.5.0+cpu) depends on torch (1.4.0)
   1: ! not torch (1.4.0) is satisfied by torch (1.4.0+cpu)
   1: ! which is caused by "bla depends on torch (1.4.0+cpu)"
   1: ! thus: torchvision is forbidden
   1: ! torchvision (0.5.0+cpu) is satisfied by torchvision (0.5.0+cpu)
   1: ! which is caused by "bla depends on torchvision (0.5.0+cpu)"
   1: ! thus: version solving failed

As said in the first line of the debug output, the package torchvision (0.5.0+cpu) depends on torch (1.4.0). However, I've specified that I need torch (1.4.0+cpu). The PEP says that the local identifier MUST be ignored when performing the version match for the constraint coming from the torchvision (0.5.0+cpu) package. So I would say that this conflict is actually an acceptable solution, given the constraints.

Note that Pip has no problem installing this combination of packages.

This is an issue with Poetry's solver.

[stadlerb]

Same problem here - is there any way to disable URL filename version checking?

[Jefffish09]

Same problem.

I tried to install pytorch and torchvision with local .whl files via these command:

poetry add https://download.pytorch.org/whl/cpu/torch-1.6.0%2Bcpu-cp38-cp38-linux_x86_64.whl
poetry add https://download.pytorch.org/whl/cpu/torchvision-0.7.0%2Bcpu-cp38-cp38-linux_x86_64.whl

When I install pytorch, it was successful.
But when install torchvision, it showed below:

[SolverProblemError]
Because torchvision (0.7.0+cpu) depends on torch (1.6.0) and machinelearning depends on torch (1.6.0+cpu https://download.pytorch.org/whl/cpu/torch-1.6.0%2Bcpu-cp38-cp38-linux_x86_64.whl), torchvision is forbidden. So, because machinelearning depends on torchvision (0.7.0+cpu https://download.pytorch.org/whl/cpu/torchvision-0.7.0%2Bcpu-cp38-cp38-linux_x86_64.whl), version solving failed.

How can I solve this?

[Korijn]

You can't, the resolver or the package's dependencies need to change and so far both parties aren't acting on this.

I have fallen back to managing all my deps except torch and vision with poetry and then installing torch and vision with pip in the virtualenv afterwards. It sucks but it's the only reliable way right now.

[Jefffish09]

You can't, the resolver or the package's dependencies need to change and so far both parties aren't acting on this.

I have fallen back to managing all my deps except torch and vision with poetry and then installing torch and vision with pip in the virtualenv afterwards. It sucks but it's the only reliable way right now.

Thanks for your reply. Hope a perfect solution will come soon.

[hhoeflin]

Is there any update on this? It is a real problem for my projects where I rely on torch.

[Korijn]

Is there any update on this? It is a real problem for my projects where I rely on torch.

I feel you! No news yet.

[pawamoy]

I wrote an ugly workaround.

In pyproject.toml, I specify torch and torchvision using +cpu:

torch = "1.5.1+cpu"
torchvision = "0.6.1+cpu"

I added a lock duty (a task written in Python) that performs these steps:

1. temporarily change torch = "1.5.1+cpu" to torch = "1.5.1" in pyproject.toml
2. run poetry lock
3. modify the lock file to use the CPU version of torch

Here is the monster:

@duty
def fix_torch_lock(ctx):
    def _fix_torch_lock():
        lock_file = Path("poetry.lock")
        lock_lines = lock_file.read_text().splitlines(keepends=False)
        in_torch_package = False
        for index, line in enumerate(lock_lines):
            if line == 'name = "torch"':
                in_torch_package = True
            elif line == 'version = "1.5.1"' and in_torch_package:
                lock_lines[index] = 'version = "1.5.1+cpu"'
                in_torch_package = False
            elif line == 'torch = "1.5.1"':
                lock_lines[index] = 'torch = "1.5.1+cpu"'
            elif line.startswith('    {file = "torch-1.5.1-'):
                lock_lines[index] = "\n".join([
                    '    {file = "torch-1.5.1+cpu-cp36-cp36m-linux_x86_64.whl", hash = "md5:UPDATE-ME"},',
                    '    {file = "torch-1.5.1+cpu-cp36-cp36m-win_amd64.whl", hash = "md5:UPDATE-ME"},',
                    '    {file = "torch-1.5.1+cpu-cp38-cp38-linux_x86_64.whl", hash = "md5:UPDATE-ME"},',
                    '    {file = "torch-1.5.1+cpu-cp38-cp38-win_amd64.whl", hash = "md5:UPDATE-ME"},',
                ])
            elif line == "[[package]]" and in_torch_package:
                in_torch_package = False
        lock_file.write_text("\n".join(lock_lines))
    ctx.run(_fix_torch_lock, title="Fixing poetry.lock for torch")


@contextlib.contextmanager
def use_torch_no_cpu():
    pyproject_file = Path("pyproject.toml")
    original_contents = pyproject_file.read_text()
    temp_contents = re.sub(r'torch = "1\.5\.1\+cpu"', 'torch = "1.5.1"', original_contents)
    try:
        pyproject_file.write_text(temp_contents)
        yield
    finally:
        pyproject_file.write_text(original_contents)


@duty(post=[fix_torch_lock], capture=False)
def lock(ctx):
    with use_torch_no_cpu():
        ctx.run("poetry lock")

I wasn't sure about the sensitivity of the MD5 sums, so I redacted them. You can easily find them by running poetry add torch==1.5.1+cpu in a fresh poetry project and checking the lock file.

Note that this is very, very specific to my use case. The only version supported by this code is 1.5.1, for Python 3.6 or 3.8.

I can now run poetry run duty lock, and Poetry won't fail while locking, and I'll have the CPU version of torch listed in the lock file.

[DriverX]

Same problem.

I have not found any legal way to solve this problem and remove poetry from project =(

[kikohs]

After spending a couple of hours on this issue, I found a "solution" by combining Poetry and pip just for PyTorch. You don't need to specify the wheel URLs directly and thus remain cross-platform.

I'm using Poe The Poet, a nice task runner for Poetry that allows to run any arbitrary command.

[tool.poetry.dev-dependencies]
poethepoet = "^0.10.0"

[tool.poe.tasks]
force-cuda11 = "pip3 install torch==1.8.0+cu111 torchvision==0.9.0+cu111 -f https://download.pytorch.org/whl/torch_stable.html"

You can run:

poetry install

and then:

poe force-cuda11  # relies on pip and use PyTorch wheels repo

Hope it helps.

[fishbotics]

Adding a datapoint here, I tried just manually adding the URLs for torch and torchvision in my pyproject.toml file as follows:

[tool.poetry.dependencies]    
python = "3.9.1"    
torchvision = {url = "https://download.pytorch.org/whl/cu111/torchvision-0.9.0%2Bcu111-cp39-cp39-linux_x86_64.whl"}    
torch = {url = "https://download.pytorch.org/whl/cu111/torch-1.8.0%2Bcu111-cp39-cp39-linux_x86_64.whl" }  

But then when I run poetry update, I get this issue:

  Because YOUR_PACKAGE depends on torchvision (0.9.0+cu111 url) which depends on torch (1.8.0), torch is required.
  So, because YOUR_PACKAGE depends on torch (1.8.0+cu111 url), version solving failed.

[yonimedhub]

any news on this? still a problem with pytorch...

[niteshthakur]

@Korijn If the specified version identifier is a public version identifier (no local version label), then the local version label of any candidate versions MUST be ignored when matching versions. IMO the above statement means that local version should be ignored from candidate versions when matching against a specified version. However in your case, you have local version specified and thus following stmt holds from 440 If the specified version identifier is a local version identifier, then the local version labels of candidate versions MUST be considered when matching versions, with the public version identifier being matched as described above, and the local version label being checked for equivalence using a strict string equality comparison. It appears that poetry is doing it correctly here.

[Korijn]

Take the following two statements:

• If the specified version identifier is a public version identifier (no local version label), then the local version label of any candidate versions MUST be ignored when matching versions.
• torchvision (0.5.0+cpu) depends on torch (1.4.0)

The specified version identifier for the dependency is 1.4.0, no local version label! Therefore, the local version label of any candidate MUST be ignored when matching versions. Therefore, 1.4.0+cpu is an acceptable candidate version.

• If the specified version identifier is a local version identifier, then the local version labels of candidate versions MUST be considered when matching versions, with the public version identifier being matched as described above, and the local version label being checked for equivalence using a strict string equality comparison

This if statement is not matched, because the specified version identifier is 1.4.0 which is not a local version identifier.

[niteshthakur]

Take the following two statements:

• If the specified version identifier is a public version identifier (no local version label), then the local version label of any candidate versions MUST be ignored when matching versions.
• torchvision (0.5.0+cpu) depends on torch (1.4.0)

The specified version identifier for the dependency is 1.4.0, no local version label! Therefore, the local version label of any candidate MUST be ignored when matching versions. Therefore, 1.4.0+cpu is an acceptable candidate version.

• If the specified version identifier is a local version identifier, then the local version labels of candidate versions MUST be considered when matching versions, with the public version identifier being matched as described above, and the local version label being checked for equivalence using a strict string equality comparison

This if statement is not matched, because the specified version identifier is 1.4.0 which is not a local version identifier.

What if a local version changes what torchvision depends on ?

[Korijn]

I don't see how that is relevant.

[stadlerb]

@niteshthakur:
In your eyes, does "specified version identifier" only refer to version identifiers specified in the pyproject.toml of the current project or also to version identifiers of transitive dependencies? If so:

• The current project specifies torch==1.4.0+cpu, which is a non-public identifier, as you pointed out.
• Thus, the local version +cpu must be considered when matching candidates for torch in the context of the current project's immediate dependencies. Only torch with version 1.4.0+cpu can satisfy this.
• The torchvision package specifies torch==1.4.0 as a dependency, which is a public identifier (and the dependency is a transitive one from the current project's perspective)
• Thus, the local version identifier of the candidate torch==1.4.0+cpu has to be ignored when matching the transitive dependency torch==1.4.0 specified in torchvision against the candidate torch==1.4.0+cpu.
• This appears not to be the case as the debug line 1: ! not torch (1.4.0) is satisfied by torch (1.4.0+cpu) indicates.

[niteshthakur]

@stadlerb IMO, the version matching rules should apply to all types of dependencies and not just direct. At the same time :

• torchvision depends on torch==1.4.0 and thus it can also depend on torch==1.4.0+cpu.
• However, it could be that while determining the candidates, poetry doesn't include the local versions(maybe it doesn't know where to get that information since local versions are unknown to it or are they not ? ) and hence the debug logs.

[stadlerb]

@niteshthakur So are we on the same page that poetry might be doing something wrong here? After all, there seems to be no reason to require torch version 1.4.0 without local modifier, but only to require 1.4.0 with any local modifier allowed (including none).

[niteshthakur]

@stadlerb this definitely is a special case for poetry to handle where it should include the local specified versions also as candidate versions.

[xvr-hlt]

Any updates? This is currently blocking us from rolling out Poetry to any of our projects that use torch.

[psinger]

This is still not solved :/

[colindean]

I hit this hard again today.

I seem unable to install torchvision 0.5.0+cu100 on Linux after Poetry installs dependencies fine on macOS, choosing 0.5.0 package specific to macOS, effectively. I'm using Poetry 1.1.10 installed with install-poetry.py on Python 3.7.1 (I know it's older but it's what's, unfortunately, necessary for this project right now).

The error when running poetry install inside a container running our CI that is a little more than some inside-the-firewall stuff on top of python:3.7-buster:

Invalid hashes (sha256:4943355e6e3ea33c8e9b9c475d6b9a4b9bb8e69b1991c93e8a6b80207841bf34) for torchvision (0.5.0+cu100) using archive torchvision-0.5.0+cu100-cp37-cp37m-linux_x86_64.whl. Expected one of sha256:0ca9cae9ddf1784737493e201aa9411abe62a4479b2e67d1d51b4b7acf16f6eb, sha256:1a68d3d98e074d995f3d42a492cca716b0d94605a6fadddf0ce9665425968669, sha256:1af6d7b0a515d2a83fe9b6e7969b57ba94ba87a3333e7ed707324a5be1ef5f60, sha256:2bf1dc1e16c73c5810d96e4ea463e61129e890100740cd57724413a84d301e41, sha256:323500d349d8d91ce2662de41212e8eb1845c68dbf5d4f215ca1e94c7f20723b, sha256:358967343eaba74fd748a87f40ea75ca23757e947dbef9a11cd53414d707f793, sha256:35e9483858cf8a38debc647c74741605c5c12448d314aa96961082380aadf7e5, sha256:4dd05cbc497210928ae3d4d6194561985263c879c3554e9f1823a0fa43d35746, sha256:517425af7d41b64caae0f5d9e6b14eeb48d6e62d45f302b73a11a9ec5ee3b6c8, sha256:78d455a1da7d10bd38f2e2a0d2ac285e4845c9e7e28aafdf068472cc96bd156b, sha256:9e85ba17ff93a0cf6afd39b9a0ad56ca7321db4f1eb90d2034d3b0ecd79be47b, sha256:a696ec5009eb52356508eb9b23ddb977043fb82ff7b204459e4c81aca1e5affe, sha256:aa4354d339de2c5ea2633a6c94294c68bae3e42a4b099624299e2a50c9e97a85, sha256:ec7e4cd54f5ff3a889b90f24b33da1fa9fe3f78d17348965678d9503de1e4a49, sha256:fea3d431bf639c0719afff5972eb568ebe143eba447c1c8bb491c7dfb0025ed6.

I validated the hash for the whl file I expect it to use, and which it seems to want to use:

$ wget https://download.pytorch.org/whl/cu100/torchvision-0.5.0%2Bcu100-cp37-cp37m-linux_x86_64.whl
$ sha256 torchvision-0.5.0+cu100-cp37-cp37m-linux_x86_64.whl
4943355e6e3ea33c8e9b9c475d6b9a4b9bb8e69b1991c93e8a6b80207841bf34  torchvision-0.5.0+cu100-cp37-cp37m-linux_x86_64.whl

This hash matches the one that Poetry reports.

I don't know where Poetry got these hash candidates, but I'll bet that it's related to this in my pyproject.toml:

[tool.poetry.dependencies]
torchvision = [
    { version = "0.5.0+cu100", markers = "sys_platform == 'linux'"},
    { version = "0.5.0", markers = "sys_platform == 'darwin'"}
]

My lockfile was generated on macOS…

Mirror the repository with:

curl https://eternalphane.github.io/pytorch-pypi/torchvision/ \
| rg -o "https(.*)whl\"" \
| sed -e 's/"//g' \
| aria2c -d . -i - -x $(nproc)

(See the aside below if you're confused about this repo URL for PyTorch.)

Then hash everything:

sha256 * > hashes

And look for the hashes in the hashes file:

for i in sha256:0ca9cae9ddf1784737493e201aa9411abe62a4479b2e67d1d51b4b7acf16f6eb, sha256:1a68d3d98e074d995f3d42a492cca716b0d94605a6fadddf0ce9665425968669, sha256:1af6d7b0a515d2a83fe9b6e7969b57ba94ba87a3333e7ed707324a5be1ef5f60, sha256:2bf1dc1e16c73c5810d96e4ea463e61129e890100740cd57724413a84d301e41, sha256:323500d349d8d91ce2662de41212e8eb1845c68dbf5d4f215ca1e94c7f20723b, sha256:358967343eaba74fd748a87f40ea75ca23757e947dbef9a11cd53414d707f793, sha256:35e9483858cf8a38debc647c74741605c5c12448d314aa96961082380aadf7e5, sha256:4dd05cbc497210928ae3d4d6194561985263c879c3554e9f1823a0fa43d35746, sha256:517425af7d41b64caae0f5d9e6b14eeb48d6e62d45f302b73a11a9ec5ee3b6c8, sha256:78d455a1da7d10bd38f2e2a0d2ac285e4845c9e7e28aafdf068472cc96bd156b, sha256:9e85ba17ff93a0cf6afd39b9a0ad56ca7321db4f1eb90d2034d3b0ecd79be47b, sha256:a696ec5009eb52356508eb9b23ddb977043fb82ff7b204459e4c81aca1e5affe, sha256:aa4354d339de2c5ea2633a6c94294c68bae3e42a4b099624299e2a50c9e97a85, sha256:ec7e4cd54f5ff3a889b90f24b33da1fa9fe3f78d17348965678d9503de1e4a49, sha256:fea3d431bf639c0719afff5972eb568ebe143eba447c1c8bb491c7dfb0025ed6; do echo $i; done | cut -d ':' -f 2 | sed 's/,//g' | xargs -t -I % rg % hashes

Three hits:

rg 0ca9cae9ddf1784737493e201aa9411abe62a4479b2e67d1d51b4b7acf16f6eb hashes
rg 1a68d3d98e074d995f3d42a492cca716b0d94605a6fadddf0ce9665425968669 hashes
rg 1af6d7b0a515d2a83fe9b6e7969b57ba94ba87a3333e7ed707324a5be1ef5f60 hashes
rg 2bf1dc1e16c73c5810d96e4ea463e61129e890100740cd57724413a84d301e41 hashes
rg 323500d349d8d91ce2662de41212e8eb1845c68dbf5d4f215ca1e94c7f20723b hashes
rg 358967343eaba74fd748a87f40ea75ca23757e947dbef9a11cd53414d707f793 hashes
rg 35e9483858cf8a38debc647c74741605c5c12448d314aa96961082380aadf7e5 hashes
rg 4dd05cbc497210928ae3d4d6194561985263c879c3554e9f1823a0fa43d35746 hashes
rg 517425af7d41b64caae0f5d9e6b14eeb48d6e62d45f302b73a11a9ec5ee3b6c8 hashes
251:517425af7d41b64caae0f5d9e6b14eeb48d6e62d45f302b73a11a9ec5ee3b6c8  torchvision-0.5.0-cp38-cp38-macosx_10_9_x86_64.whl
rg 78d455a1da7d10bd38f2e2a0d2ac285e4845c9e7e28aafdf068472cc96bd156b hashes
252:78d455a1da7d10bd38f2e2a0d2ac285e4845c9e7e28aafdf068472cc96bd156b  torchvision-0.5.0-cp38-cp38-win_amd64.whl
rg 9e85ba17ff93a0cf6afd39b9a0ad56ca7321db4f1eb90d2034d3b0ecd79be47b hashes
rg a696ec5009eb52356508eb9b23ddb977043fb82ff7b204459e4c81aca1e5affe hashes
rg aa4354d339de2c5ea2633a6c94294c68bae3e42a4b099624299e2a50c9e97a85 hashes
250:aa4354d339de2c5ea2633a6c94294c68bae3e42a4b099624299e2a50c9e97a85  torchvision-0.5.0-cp38-cp38-linux_x86_64.whl

Then I go look at poetry.lock:

torchvision = [
    {file = "torchvision-0.5.0-cp27-cp27m-macosx_10_7_x86_64.whl", hash = "sha256:35e9483858cf8a38debc647c74741605c5c12448d314aa96961082380aadf7e5"},
    {file = "torchvision-0.5.0-cp27-cp27m-manylinux1_x86_64.whl", hash = "sha256:323500d349d8d91ce2662de41212e8eb1845c68dbf5d4f215ca1e94c7f20723b"},
    {file = "torchvision-0.5.0-cp27-cp27mu-manylinux1_x86_64.whl", hash = "sha256:ec7e4cd54f5ff3a889b90f24b33da1fa9fe3f78d17348965678d9503de1e4a49"},
    {file = "torchvision-0.5.0-cp35-cp35m-macosx_10_6_x86_64.whl", hash = "sha256:4dd05cbc497210928ae3d4d6194561985263c879c3554e9f1823a0fa43d35746"},
    {file = "torchvision-0.5.0-cp35-cp35m-manylinux1_x86_64.whl", hash = "sha256:9e85ba17ff93a0cf6afd39b9a0ad56ca7321db4f1eb90d2034d3b0ecd79be47b"},
    {file = "torchvision-0.5.0-cp35-cp35m-win_amd64.whl", hash = "sha256:2bf1dc1e16c73c5810d96e4ea463e61129e890100740cd57724413a84d301e41"},
    {file = "torchvision-0.5.0-cp36-cp36m-macosx_10_9_x86_64.whl", hash = "sha256:358967343eaba74fd748a87f40ea75ca23757e947dbef9a11cd53414d707f793"},
    {file = "torchvision-0.5.0-cp36-cp36m-manylinux1_x86_64.whl", hash = "sha256:fea3d431bf639c0719afff5972eb568ebe143eba447c1c8bb491c7dfb0025ed6"},
    {file = "torchvision-0.5.0-cp36-cp36m-win_amd64.whl", hash = "sha256:1a68d3d98e074d995f3d42a492cca716b0d94605a6fadddf0ce9665425968669"},
    {file = "torchvision-0.5.0-cp37-cp37m-macosx_10_9_x86_64.whl", hash = "sha256:1af6d7b0a515d2a83fe9b6e7969b57ba94ba87a3333e7ed707324a5be1ef5f60"},
    {file = "torchvision-0.5.0-cp37-cp37m-manylinux1_x86_64.whl", hash = "sha256:a696ec5009eb52356508eb9b23ddb977043fb82ff7b204459e4c81aca1e5affe"},
    {file = "torchvision-0.5.0-cp37-cp37m-win_amd64.whl", hash = "sha256:0ca9cae9ddf1784737493e201aa9411abe62a4479b2e67d1d51b4b7acf16f6eb"},
    {file = "torchvision-0.5.0-cp38-cp38-macosx_10_9_x86_64.whl", hash = "sha256:517425af7d41b64caae0f5d9e6b14eeb48d6e62d45f302b73a11a9ec5ee3b6c8"},
    {file = "torchvision-0.5.0-cp38-cp38-manylinux1_x86_64.whl", hash = "sha256:aa4354d339de2c5ea2633a6c94294c68bae3e42a4b099624299e2a50c9e97a85"},
    {file = "torchvision-0.5.0-cp38-cp38-win_amd64.whl", hash = "sha256:78d455a1da7d10bd38f2e2a0d2ac285e4845c9e7e28aafdf068472cc96bd156b"},
]

Sure enough, the lockfile only has the macOS branch of the conditional
dependency. Shouldn't PyTorch be locking the dependencies for all conditional
branches?

Or do I need to generate this lockfile on Linux? If I generate it on Linux,
will I see the same error on macOS when I try to install the dependencies in my
dev workstation?

Aside on PyTorch repo

This repo https://eternalphane.github.io/pytorch-pypi/torchvision/ is a PyPI-compatible relisting of PyTorch's original downloads page, which was only usable with pip --find-links. PyTorch has since shipped a PyPI-compatible repo https://download.pytorch.org/whl/cu100/torchvision/ but I can't use it because apparently, Poetry will try to download every package from it:

RepositoryError

  403 Client Error: Forbidden for url: https://download.pytorch.org/whl/cu100/torchvision/types-deprecated/

  at ~/.pyenv/versions/3.7.1/lib/python3.7/site-packages/poetry/repositories/legacy_repository.py:393 in _get

[radoering]

Can you check if this issue is still present in poetry 1.2.0b1?

I was able to successfully run poetry lock with the following dependencies:

[tool.poetry.dependencies]
python = "~3.9"
torch = { path = "torch-1.11.0+cpu-cp39-cp39-win_amd64.whl" }
torchvision = { path = "torchvision-0.12.0+cpu-cp39-cp39-win_amd64.whl" }

[abn]

Closing this as the original seems to be resolved as per @radoering 's comment. Poetry >=1.2.0b1 should work for these cases.

[Korijn]

I'll try to confirm as @radoering's example configuration locks on path dependencies and therefore doesn't seem representative of the original provided reproduction example.

[psinger]

There is also a long post here stating this issue still exists: #4231 (comment)

Not sure this is solved and can be closed.

[abn]

I have responded to that comment. Reopening this, however I suspect this might be fixed with #4729.

[github-actions]

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.