We require contributors to sign our Contributor License Agreement and we don't have one on file for @harnvo.

In order for us to review and merge your code, please e-sign the Contributor License Agreement PDF. We then need to manually verify your signature, merge the PR (conda/infrastructure#966), and ping the bot to refresh the PR.

I feel this type of support would belong better in a Python-specific plugin like the one we are implementing at conda-pypi. We will also need some more plugin hooks in conda and conda env to allow additional file formats.

Thanks for your insight.

I feel this type of support would belong better in a Python-specific plugin like the one we are implementing at conda-pypi.

Not sure if I have understood everything correctly. "Having support for pyproject.toml" means we could configure & manage our project with conda pyproject.toml. This is something cannot be done soloy with better support for PyPI.

IMO, having another FileSpec is mandatory for this feature, and it is just the matter of how. Maybe you meant a plugin that makes PEP 508 syntax compatible with conda?

We will also need some more plugin hooks in conda and conda env to allow additional file formats.

I would agree having more plugin hooks is a less hacky way for implementing this feature. However, I believe the biggest problem lies in the fact that conda assumes one file contains exactly one environment, which is no longer true for pyproject.toml.

@conda-bot check

These days you can install the conda-pypi alpha and do conda pip install . on your PyPI project.

One key aspect to remember is that conda is a language-agnostic package manager. Python has been special cased in the past but in the future we'd rather have language-specific plugins dealing with the oddities of each ecosystem. We are slowly adding more and more plugin hooks to make this possible.

I don't have a clear idea of what you are trying to achieve when you say "Add support for pyproject.toml". I can see several possible strategies:

• Install a project from their git repository, installing Python and pip with conda, and the rest from PyPI
• Create an environment using both pyproject.toml and environment.yml?
• Create an environment using only pyproject.toml, which would have a new tool.conda section with the conda deps?

I'm not trying to be dismissive, but I am more interested in seeing this implemented at the right level, with the right scope, and maybe as a plugin (which could be eventually be included by default as a conda dependency; being a plugin doesn't have to mean it's not part of the "core" experience). I appreciate the prototypes because the inform the conversation, I think we would benefit from discussing the scope back in the originating issue.

Aside from the other concerns raised, I feel obliged to point out that the consensus on the python.org forums e.g. in this thread or this one is that the project.dependencies table in pyproject.toml should not be used for any purposes other than for building a package for distribution (via PyPI).

I.e. PyPI packages must specify their own dependencies there, as should things being built, but it should not be used to provide arbitrary lists of dependencies required to be installed in an environment to run or work on some project.

PEP-735 is being worked on to provide a standardized way for precisely this, and once it's passed, maybe conda could support that in some form.

But while I don't know enough about packaging for conda distribution to know how conda packages specify their own dependencies (perhaps it's also in environment.yml), I do know that environment.yml is often used for projects that are not being either installed or packaged for distribution – the exact use-case which is being explicitly discouraged from utilizing project.dependencies.

So for now I think it is a really bad idea to try and make conda support dependency specification within pyproject.toml unless the supported place to specify the dependencies is contained entirely within a [tool.conda] table.

Hence my suggestion in the issue you linked as to how [tool.conda.environment] could – prior to finalization of the PEP – be parsed as if it was an environment.yml file.

I disagree with the forums; why not allow such a list to be directly installed? Deliberately unhelpful.

We could have a general facility for installing a list of requirements given an arbitrary key within thing-that-can-be-parsed-as-a-dict (toml, json, yaml). "install <file.toml> --from-key tool.conda.requirements or --from-key forbidden-by-forums.requirements"

Yeah I know, it does seem a bit pointlessly stubborn. But those discussions are settled it seems, and surely it would also be pretty deliberately unhelpful to move now, while a standardization effort is ongoing, to actively support the one way in which such lists of dependencies definitely won't be included in a pyproject.toml. Doesn't hurt to wait for the outcome.

We could have a general facility for installing a list of requirements given an arbitrary key within thing-that-can-be-parsed-as-a-dict (toml, json, yaml). "install <file.toml> --from-key tool.conda.requirements or --from-key forbidden-by-forums.requirements"

I agree with this general idea. However, this does not solve his concern IMO.

project.dependencies are used by setuptools. Allowing conda to create environment from project.dependencies without channel restriction could make conda-managed projects uninstallable via setuptools. (Well, yes, this has always been the case. But formerly setuptools won't use environment.yml and conda doesn't use pyproject.toml. There should at least be an compatibility warning.)