Support configuration options from `pyproject.toml`, even when not using `-f pyproject.toml`

[MattF-NSIDC]

Checklist

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

What is the idea?

Currently, when I put config in pyproject.toml, conda-lock does not respect it.

[tool.conda-lock]
platforms = ['linux-64', 'osx-64']

With this config, I run conda-lock, and it still tries to build for win-64:

$ conda-lock
Locking dependencies for ['linux-64', 'osx-64', 'win-64']...

My understanding from reading the docs is that pyproject.toml is only evaluated for configuration options if -f pyproject.toml is passed. I don't think there is any way to save the desired list of platforms when generating a lock file from environment.yml.

Why is this needed?

I'd prefer not to have everyone on my project remember to pass -p linux-64 and -p osx-64 every time they lock an env. I always want those two platforms and nothing else.

What should happen?

pyproject.toml should always be evaluated for configuration options regardless of which file is being used for environment specification.

I expected this because tools like black, ruff, mypy are all capable of using pyproject.toml for their configuration options. Things are maybe a touch more confusing for conda-lock because pyproject.toml can also be treated as an input data file, but I think it's still intuitive for conda-lock to always respect configuration options (not install_dependencies) specified there.

Additional Context

No response

[maresb]

I don't think there is any way to save the desired list of platforms when generating a lock file from environment.yml.

There is. It's not a standard key, but you can do

platforms:
- linux-64
- osx-64

Regarding automatically reading pyproject.toml, I'm not so sure that's a good idea. I'd rather keep things explicit. I have many reasons to be reluctant, although none are particularly compelling. It raises questions like what if environment.yml and pyproject.toml are present. Do you want one or the other or both? Also I'm a bit reluctant to overly promote pyproject.toml usage until it's more stable.

I suspect this may be popular and useful, but I want to think through the implications and make sure it's not a footgun. I'm open to feedback.

[MattF-NSIDC]

Thanks for the response! TIL about the non-standard platform key. I see that in the README now!

In my first pass of the README, I jumped straight to the pyproject.toml section (I did CTRL+F pyproject and skipped over all the other important stuff ;) ) because it seemed intuitive to me to configure this tool in the same way as all my other tools, i.e. [tool.nameoftool], and I figured I knew all there was to know about environment.yml :)

[maresb]

That's completely understandable, and thanks a lot for the really feedback.

Conda and related tools are neither Python-specific nor project-specific, so in my mental model it doesn't make much sense to manage them with pyproject.toml. However Conda stuff is undeniably Python-centric, so most users of conda-lock are probably managing Python projects, and are sufficiently standards-aware to be using pyproject.toml. Thus your thought process may well be the prevalent one.

I'm curious about the opinions of @mariusvniekerk and others.

[MattF-NSIDC]

Conda and related tools are neither Python-specific nor project-specific, so in my mental model it doesn't make much sense to manage them with pyproject.toml

This is an excellent point that I need to constantly remind myself, despite the fact that I regularly pull non-Python tools from conda-forge.

thanks a lot for the really feedback

Thanks for being welcoming to feedback :heart:

your thought process may well be the prevalent one.

Even if not, I think my thought process here is a possible pitfall that others may also encounter. I'll think about how this pitfall could be surfaced in the docs and try to open a PR that would prevent someone who thinks like me from falling in that pit :)