`pixi install` stuck during updating lock-file with Azure DevOps Artifacts Feed

jslorrma commented 2 months ago

Checks

[X] I have checked that this issue has not already been reported.
[X] I have confirmed this bug exists on the latest version of pixi, using pixi --version.

Reproducible example

pyproject.toml

# ─────────────────────────────────────────────────────────────────────────────
# Project Metadata
# ─────────────────────────────────────────────────────────────────────────────
[project]
...

# ─────────────────────────────────────────────────────────────────────────────
# Project Dependencies
# ─────────────────────────────────────────────────────────────────────────────
requires-python = ">=3.10"

dependencies = [
  "matplotlib>=3.9.2,<4",
  "msgspec>=0.18.6,<0.19",
  "networkx>=3.3,<4",
  "click>=8.1.7,<9", 
  "graphviz>=0.20.3,<0.21",
]

[project.optional-dependencies]
dev = [
  "pytest>=8.3.2,<9",
  "pytest-cov>=5.0.0,<6",
  "ruff>=0.6.0,<0.7",
  "black>=24.8.0,<25",
  "pre-commit>=3.8.0,<4",
  "ipython>=8.26.0,<9",
  "jupyterlab>=4.2.4,<5"
]

# ─────────────────────────────────────────────────────────────────────────────
# Build System Configuration
# ─────────────────────────────────────────────────────────────────────────────
[build-system]
build-backend = "hatchling.build"
requires = ["hatchling"]

...

# ─────────────────────────────────────────────────────────────────────────────
# Pixi Configuration
# ─────────────────────────────────────────────────────────────────────────────
[tool.pixi.project]
channels = ["conda-forge"]
platforms = ["linux-64", "osx-64", "win-64"]

[tool.pixi.pypi-options]
index-url = "https://pypi.org/simple"
extra-index-urls = ["https://VssSessionToken@pkgs.dev.azure.com/{organisation}/{project}/_packaging/{feedName}/pypi/simple"]

pixi.lock

version: 5
environments:
  default:
    channels:
    - url: https://conda.anaconda.org/conda-forge/
    indexes:
    - https://pypi.org/simple
    - https://VssSessionToken@pkgs.dev.azure.com/{organisation}/{project}/_packaging/{feedName}/pypi/simple/
    packages:
      linux-64:
      - conda: https://conda.anaconda.org/conda-forge/linux-64/_libgcc_mutex-0.1-conda_forge.tar.bz2
      - conda: https://conda.anaconda.org/conda-forge/linux-64/_openmp_mutex-4.5-2_gnu.tar.bz2
      - conda: https://conda.anaconda.org/conda-forge/linux-64/bzip2-1.0.8-h4bc722e_7.conda
      - ...
      - pypi: https://pkgs.dev.azure.com/{org}/{project}/_apis/packaging/feeds/6f966fae-2990-4dc7-b86d-0f2d3a81b5cd/pypi/packages/click/versions/8.1.7/click-8.1.7-py3-none-any.whl/content
      - pypi: https://pkgs.dev.azure.comorg}/{project}/_apis/packaging/feeds/6f966fae-2990-4dc7-b86d-0f2d3a81b5cd/pypi/packages/contourpy/versions/1.2.1/contourpy-1.2.1-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl/content
      - ...
 ...

config.toml

[pypi-config]
# can be "subprocess" or "disabled"
keyring-provider = "subprocess"

Issue description

First of all, great work on Pixi! It has been incredibly helpful and has resolved many of our consistency issues.

Context:

Our project uses Azure DevOps and Azure DevOps Artifacts to publish internal Python packages and mirror some standard packages from public PyPI.
We use artifacts-keyring to handle authentication for the internal Artifacts feed.
Our Pixi projects are configured using pyproject.toml

Issue Scenario:

When configuring the Azure DevOps Artifacts feed via extra-index-urls in [tool.pixi.pypi-options] table inpyproject.toml, the pixi install command hangs during updating lock-file at resolving package-xyz ... and does not complete (even after 45 minutes).
However, when setting the Azure DevOps Artifacts feed as index-url and defining https://pypi.org/simple in extra-index-urls, the installation completes without any issues.

Debugging:

Setting up an environment with some standard PyPI -packages (matplotlib, numpy, ...) without any private packages from the Azure DevOps Artifacts feed allows pixi install to work, but updating lock-file is still kind of slow (installation takes over 5 minutes). However, it does eventually finish.
Looking into pixi.lock file shows that PyPI package URLs are all from Azure DevOps Artifacts (https://pkgs.dev.azure.com/...) instead of from https://files.pythonhosted.org/packages/....
Switching index-url and extra-index-urls as described above results in a quick install and lock-file generation. In this case, the pixi.lock file shows all PyPI packages have URLs as https://files.pythonhosted.org/packages.

Expected behavior

Pixi should use index-url with highest priority and pixi install, pixi shell, ... should complete successfully without hanging, regardless of whether the Azure DevOps Artifacts feed is set as index-url or extra-index-urls.

tdejager commented 2 months ago

I don't really know why the resolution is taking so long, debugging this by running with -vvv would help. However, uv prioritizes the extra-index-urls. There is not really a way around this.

I think what we could do however is expose the no-index uv option and then you could provide both the Azure DevOps Artifacts feed and the pypi.org/simple as extra index url. With the pypi url coming first. This will essentially be the behavior that you described, note that it will then always take a package from pypi.org/simple first. Meaning that at that point your mirrored packages are not selected, only the ones not present on the official index.

Would this be sufficient?

tdejager commented 2 months ago

BTW you could take a look at these options here, we can expose more of these if it would help: https://docs.astral.sh/uv/reference/settings/#pip_index-url

jslorrma commented 2 months ago

I think what we could do however is expose the no-index uv option and then you could provide both the Azure DevOps Artifacts feed and the pypi.org/simple as extra index url. With the pypi url coming first. This will essentially be the behavior that you described, note that it will then always take a package from pypi.org/simple first. Meaning that at that point your mirrored packages are not selected, only the ones not present on the official index.

Would this be sufficient?

Expose it as a configuration in pixi.toml or pyproject.toml, or just as a CLI option?

Having it as a configuration parameter would be fine. While it doesn't solve an issue directly, since, as mentioned, you can control the index order by swapping index-url and extra-index-urls, it could make the configuration more explicit.

Having it only as a CLI option or in the global config.toml might not be helpful, as it requires additional configuration outside the project. One of the best things about pixi is that it makes projects fully self-contained and reproducible. BTW, in this sense, it would be beneficial if the --pypi-keyring-provider subprocess CLI option or the keyring-provider = "subprocess" global config parameter could be set in pixi.toml or pyproject.toml as well.

However, uv prioritizes the extra-index-urls. There is not really a way around this. It would be helpful for other users if this information is included in the pixi documentation.

Anyhow, thanks for your response. The main goal of this issue was anyhow to document the problem and offer a solution for others who might encounter similar issues.

I think we can close this issue for now. If needed, we can address any no-index concerns in a new issue or PR.

tdejager commented 2 months ago

Alright! Thanks for the response, and I wholeheartedly agree, we want pixi.toml to be as reproducible from the file itself as possible, so I would be for exposing it in the manifest.

I also agree with the keyring-provider being able to be set from the manifest actually, will not create an issue out of it yet. But I think it something we should do in the future, will discuss this more internally.

Again, thanks for the thoughtful issue and replies. Will be closing this for now.

prefix-dev / pixi