conda-lock install fails with ParseError: Could not parse explicit URL for custom channel

[papanikos]

Checklist

• I added a descriptive title
• I searched open reports and couldn't find a duplicate

What happened?

I was trying to install a locked environment. The environment defines an extra custom public channel served from prefix.dev (https://repo.prefix.dev/papa-forge).

• environment.yml

channels:
  - conda-forge
  - https://repo.prefix.dev/papa-forge
dependencies:
  - snakerules >=0.2

Locking works as expected

❯ conda-lock -f environment.yml -p linux-64
Locking dependencies for ['linux-64']...
INFO:conda_lock.conda_solver:linux-64 using specs ['snakerules >=0.2']
 - Install lock using: conda-lock install --name YOURENV conda-lock.yml

Trying conda-lock install right after, throws a ParseError

❯ conda-lock install -n test-env
INFO:root:Retrieving notices: ...working... done
ERROR:root:
ERROR:root:ParseError: Could not parse explicit URL: https://repo.prefix.dev/papa-forge/noarch/snakerules-0.2.0-pyh4616a5c_0.conda#
ERROR:root:
Traceback (most recent call last):
  File "/home/nikos/.pixi/envs/conda-lock/bin/conda-lock", line 10, in <module>
    sys.exit(main())
             ~~~~^^
  File "/home/nikos/.pixi/envs/conda-lock/lib/python3.14/site-packages/click/core.py", line 1485, in __call__
    return self.main(*args, **kwargs)
           ~~~~~~~~~^^^^^^^^^^^^^^^^^
  File "/home/nikos/.pixi/envs/conda-lock/lib/python3.14/site-packages/click/core.py", line 1406, in main
    rv = self.invoke(ctx)
  File "/home/nikos/.pixi/envs/conda-lock/lib/python3.14/site-packages/click/core.py", line 1873, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
                           ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^
  File "/home/nikos/.pixi/envs/conda-lock/lib/python3.14/site-packages/click/core.py", line 1269, in invoke
    return ctx.invoke(self.callback, **ctx.params)
           ~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/nikos/.pixi/envs/conda-lock/lib/python3.14/site-packages/click/core.py", line 824, in invoke
    return callback(*args, **kwargs)
  File "/home/nikos/.pixi/envs/conda-lock/lib/python3.14/site-packages/click/decorators.py", line 34, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/home/nikos/.pixi/envs/conda-lock/lib/python3.14/site-packages/conda_lock/conda_lock.py", line 1613, in click_install
    install(
    ~~~~~~~^
        conda=conda,
        ^^^^^^^^^^^^
    ...<11 lines>...
        force_platform=force_platform,
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/home/nikos/.pixi/envs/conda-lock/lib/python3.14/site-packages/conda_lock/conda_lock.py", line 1672, in install
    install_func(file=lockfile)
    ~~~~~~~~~~~~^^^^^^^^^^^^^^^
  File "/home/nikos/.pixi/envs/conda-lock/lib/python3.14/site-packages/conda_lock/conda_lock.py", line 234, in do_conda_install
    _conda(additional_args)
    ~~~~~~^^^^^^^^^^^^^^^^^
  File "/home/nikos/.pixi/envs/conda-lock/lib/python3.14/site-packages/conda_lock/invoke_conda.py", line 145, in _invoke_conda
    raise subprocess.CalledProcessError(
    ...<4 lines>...
    )
subprocess.CalledProcessError: Command '['/home/nikos/.local/share/ensure-conda/conda_standalone', 'create', '--quiet', '--copy', '--file', '/tmp/conda-lock-qvvy9scx', '--yes', '--name', 'test-env']' returned non-zero exit status 1.

What should have happened

I would expect that "default" installation would work.

Workaround

Installing with the --micromamba option works, albeit with a warning having to do with the checksums.

❯ conda-lock install -n test-env --copy --micromamba
WARNING:root:warning  libmamba Could not validate package '/home/nikos/.local/share/mamba/pkgs/snakerules-0.2.0-pyh4616a5c_0/info/repodata_record.json': md5 and sha256 sum unknown.
WARNING:root:    Set safety_checks to disabled to override this warning.

Unfortunately, I am trying to use this for building a docker image and, at this point, I would like to avoid installing micromamba in there.

Possible fix

I had a look in the code to try to be more specific, here is how far I got.

• There is a regex here that grabs the filename for a provided url and is used in the explicit() function right below, which throws the error.
• The regex fails if something ends with a # without the presence of the next 32 hash characters.

Maybe urls are constructed in conda-lock with something equivalent to f"{channel}/{fn}#{md5}" and in this case the md5 is just empty which leads to the creation of a malformatted link?

---

I cannot really tell if this is a conda-lock issue, vendored conda, repodata from prefix, rattler-build which was used to build the conda package, or something else.
If you think this is not relevant for you, and requires some other fix, I would appreciate if you could point towards the correct direction.

Additional Context

• conda-lock version (installed with pixi global install conda-lock)

conda-lock --version
conda-lock, version 4.0.0

• Looking at my conda-lock.yml after the micromamba warning this is the entry for my package

- name: snakerules
  version: 0.2.0
  manager: conda
  platform: linux-64
  dependencies:
    python: '*'
  url: https://repo.prefix.dev/papa-forge/noarch/snakerules-0.2.0-pyh4616a5c_0.conda
  hash:
    md5: ''
    sha256: eaa0df748038d4f491865af3dcd56152a47066fe6dbb3f20a9816d6517295dd4
  category: main
  optional: false

md5 is definitely not defined but sha256 is. I guess that this might be a channel issue and the repodata are not complete so maybe irrelevant for this.

[maresb]

Thanks @papanikos for the detailed analysis!!!

This is the first time I've seen a channel that omits md5, so we are not prepared for this yet.

[tdejager]

Hey @maresb, happy to do something from our side if necessary :) I found out we do not save the md5 for uploaded packages in the repodata indeed only for mirrored packages.

[papanikos]

Thanks for chiming in the prefix issue @maresb. Until something is done there, I do think that conda-lock could handle this differently. I dug a little deeper:

Seems like when installing we reach this point

conda-lock/conda_lock/conda_lock.py

Lines 688 to 694 in d487939

	def format_conda_requirement(
	spec: LockedDependency, platform: str, direct: bool = False
	) -> str:
	if direct:
	# inject the environment variables in here
	return posixpath.expandvars(f"{spec.url}#{spec.hash.md5}")
	else:

which causes the malformatted url construction when the md5 is an empty string.

Taking a look at the LockedDependency and the HashModel, this should have failed validation, probably even for locking. The md5 field is set to (or written as) '' which is not None in the lockfile.

Two thoughts here:

• Validation should work. Either the validation logic should check for v.md5 is None or v.md5 == '' or rendering yaml files should write Nones as null.
• As the point above definitely doesn't solve my issue now, I 'd say that formatting the url could fallback to sha256 if there is something wrong with the md5. I don't know if there is a general consensus in the ecosystem that md5s are a hard requirement for channels.

Take all of this with a pinch of salt, as this comes just from browsing the code and not running it.

[maresb]

@tdejager, I'm just realizing that missing MD5 metadata is a significant complication in my very challenging attempts to resolve a corruption error where a subtle bug mamba-org/mamba#4095 leads to corruption that leaks into conda-lock lockfiles. The only reliable way I've found to identify corrupted conda-lock lockfiles is to look at whether or not the MD5 or SHA256 records are missing from the lockfile. So from this perspective, now would be a very unfortunate time to change the hashing behavior. I know it's difficult to make everyone happy, but anything you could do to restore MD5 from your side would be greatly appreciated by me and those struggling with lockfile corruption.

[tdejager]

Hey! So I've since enabled md5 on our upload endpoint and the mirrored sources like conda-forge have already had md5's. So newly uploaded packages should include the hashes. Unfortunately backingfilling is a bit difficult, one can either delete or yank and re-upload. Would be interesting to know what channels are casting problems, as I said the mirrored sources should be fine :)

[maresb]

Amazing, much appreciated @tdejager!!! 🙏