Checklist

• I added a descriptive title
• 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.