custom pypi repository on the local disk (`file://` urls)

[FelixSchwarz]

Checklist

• [X] I added a descriptive title
• [X] I searched open requests and couldn't find a duplicate

What is the idea?

Since #529 there is support for additional pip repositories. I would like to ask for support of local repositories, specified by a file:// url like this:

channels:
  - conda-forge
pip-repositories:
  - file:///some/path/to/local/repo/
dependencies:
  - python=3.11
  - requests=2.26
  - pip:
    - fake-private-package==1.0.0

Why is this needed?

We require some private wheels for our repo but there is no private registry in place. The easiest thing for us seems to be to put the wheels in git lfs which available for every developer. That way we do not need to operate a private pypi service and we circumvent all the hooks with regards to authentication/user accounts.

Running conda-lock with a file:// url triggers an exception by requests: requests.exceptions.InvalidSchema: No connection adapters were found for 'file:///some/path/to//'.

What should happen?

For the user it should not matter if he specifies an https:// or a file:// url. The end result should be the same assuming that both URLs are valid.

Additional Context

There is the requests-file library which hooks into requests. Maybe conda-lock could hook that into the processing chain?

The main problem I see is that conda-lock would need to ship its own version of LegacyRepository which then registers the file adapter for the session returned by its session property. A follow-up problem is that poetry issues a GET to /some/path/to/local/repo/ (instead of /some/path/to/local/repo/index.html) but I hope that the requests-file project might be open to accept a patch.

Of course that is only my idea on how to implement this. It might be easier to write a completely custom repo provider which avoids all the requests functionality.

[maresb]

Thanks, it would definitely be great to support this.

You have thought much more deeply about this than I have. Ideally we don't implement anything that increases our dependency on Poetry. (I would like to eventually switch away from it.) The requests-file project looks nice and simple. Would the necessary patch be to reroute directories to .../index.html?

I would be happy to consider a PR for this.

[FelixSchwarz]

Would the necessary patch be to reroute directories to .../index.html?

Unfortunately yes because poetry issues a request to /some/path/to/local/repo/fake-private-package/.

[maresb]

I don't think it would be problematic to vendor a patched requests-file in conda-lock, but upstreaming it would be preferable.

[FelixSchwarz]

I submitted #538 as a kind of draft PR

[pplonski]

Hi, I would like to use this feature as well. Any update on it? Thank you.