Skip to content

pytorch libs poetry installation on different operating systems

pytorch libs poetry installation on different operating systems

Poetry python library allows, in an easy manner, to track package dependencies within a project. It creates a snapshot of the environment in a form of a lockfile, containing packages names with installed versions, to ensure ease of repeatable installations. That is super helpful for maintaining same setups on development and production environments or for ensuring developers to have the same working space.

However I experienced a problem with poetry when trying to capture a package which has different versions for different operating systems. That happened to be the case with 4 pytorch related libraries:

  • torch_scatter
  • torch_sparse
  • torch_cluster
  • torch_spline_conv

HOW TO

To install poetry within you project, follow steps from the official documentation. I was using Python 3.9 and poetry 1.4.0.

In a nutshell, poetry provides you with a pyproject.toml file, where you specify your package requirements. It is used to orchestrate your project and its dependencies. Based on this file, the poetry.lock file is being created, which captures information about the environment.

Generally what you do is set desired packages versions in this pyproject.toml file, following the pattern. To simplify the example I stick to one of the mentioned pytorch package, but the problem and solution can easily be transferred for the 3 remaining ones.

The caret (^) in front of 1.6.0 is one of the versioning constraints that poetry provides. It means that poetry can install any version that matches the leftmost non-zero digit of the version string. In this case using 1.6.1 or 1.7 is allowed, but version 2.0 wouldn’t be allowed.

With such a setup, after you update lockfile, using the command:

you get following entry for the torch-cluster package:

As you can see, automatically version 1.6.0+pt112cpu was picked up and logged. If you inspect closer, you may notice that only installations for Windows and Linux operating systems were found. That leads to an installation error when trying to recreate the environment on MacOS:

After further inspection you may find that it is because particular MacOS package exists noted as version 1.6.0, so it is different than the one that was automatically picked up (1.6.0+pt112cpu). You may check it out here. As I wanted my installation to also cover MacOS, I needed some other way of setting it all up.

What if we set the package version strictly to 1.6.0?

Actually the situation will remain exactly the same… Still version 1.6.0+pt112cpu gets picked up.

You may try to explicitly hardcode the version in lockfile (which should not be done, but for the sake of the experiment):

That will result in only MacOS related version being recorded!

So how can we solve that? Well, you may try to install this library manually following the description.

Alternatively, in a more automated way, you may leverage the option to set up version specification based on the operating system in the pyproject.toml file, using sys_platform parameter:

  • sys_platform == win32, for Windows
  • sys_platform == linux, for Linux
  • sys_platform == darwin, for MacOS

Additionally, you may relate it to python version with python_version option.

Now, after update, we can observe 6 entries in poetry.lock file, each for the specific configuration:

That solves the issue, however requires some more entries to be specified.

The same situation applies to 3 additional pytorch packages mentioned at the beginning:

  • torch_scatter
  • torch_sparse
  • torch_spline_conv

They can be specified in the pyproject.toml file in the exact same manner, using sys_platform parameter.

Leave a Reply

Your email address will not be published. Required fields are marked *