Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(manager:conda): add manager for conda #17156

Closed
wants to merge 1 commit into from

Conversation

morremeyer
Copy link
Contributor

Changes

This is a first implementation of a manager for conda as discussed in #2213.

It has very limited support for version specifications, namely: only exact matching of release versions that have three components and can therefore be assumed to be semver compliant.

Context

Conda versioning and dependency definitions are very different from what renovate already supports.

@ekeih and I discussed how to best get something of value to all renovate users where we can guarantee that updates are correct, but without making this a huge initial implementation with full conda versioning support and all shenanigans.

We therefore implemented this limited support to get started and get familiar with the codebase (again).

If you're visiting this PR in the future: We're actively talking to the maintainers about how we can improve the support over time. There's already several ideas for improvements already.

Documentation

  • I have updated the documentation, or
  • No documentation update is required

How I've tested my work (please tick one)

I have verified these changes via:

  • Code inspection only, or
  • Newly added/modified unit tests, or
  • No unit tests but ran on a real repository, or
  • Both unit tests + ran on a real repository

Co-authored-by: Max Rosin <mrosin@anaconda.com>
Co-authored-by: Maurice Meyer <mmeyer@anaconda.com>
Copy link
Member

@viceice viceice left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it seems channels should be part of the registry url, one for each channel. that would make more sense in my eyes

const res = extractPackageFile(environmentYml);
expect(res?.deps.filter((dep) => dep.skipReason)).toHaveLength(9);
expect(res?.deps).toHaveLength(12);
expect(res).toMatchSnapshot();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please read our best practices guide and don't use toEqual or toMatchObject. reduce deps in fixture to minimum

guide is in docs/development folder

export function extractPackageFile(content: string): PackageFile | null {
let parsedContent: CondaEnvironment;
try {
parsedContent = load(content, { json: true }) as any;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cast to correct type

const releaseVersionRegex = regEx(/^(?<version>(\d+\.){1,2}\d)$/);

export function extractPackageFile(content: string): PackageFile | null {
let parsedContent: CondaEnvironment;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
let parsedContent: CondaEnvironment;
let parsedContent: CondaEnvironment | null;

yaml load can return null for empty docs

Comment on lines +44 to +51
return {
deps: [
{
depName: 'nodefaults',
skipReason: 'invalid-config',
},
],
};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

return null instead

}

const deps: PackageDependency[] = [];
parsedContent.dependencies?.forEach((parsedDep) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use for...of loop, checkout best practices


/* eslint-disable-next-line @typescript-eslint/restrict-template-expressions */
cloneDep.depName = `${channel}/${cloneDep.depName}`;
cloneDep.packageName = cloneDep.depName;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if it's same as depName, remove

// version used and set it explicitly.
if (versionMatch?.groups?.version && groups.exact === '==') {
dep.currentVersion = groups.version;
dep.versioning = 'semver';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think you should use pep440 versioning instead, as it will support most of your limitations

@rarkins rarkins marked this pull request as draft December 17, 2022 06:41
@@ -0,0 +1,17 @@
Supports conda `environment.yml` files.

Renovate has no concept of conda channels and their different priorities. The manager will open separate PRs for updates from different channels. This allows you to make a decision about which updates to merge.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Renovate has no concept of conda channels and their different priorities. The manager will open separate PRs for updates from different channels. This allows you to make a decision about which updates to merge.
Renovate has no concept of conda channels and their different priorities.
The manager will open separate PRs for updates from different channels.
This allows you to make a decision about which updates to merge.

We use the "one sentence per line" pattern in our docs.


**Warning**

When enabling the manager, you will get _Package Lookup Warnings_ for all packages that are not present in all channels. This is, again, due to renovate not having a concept of conda channels and treating each package for each channel as a separate dependency. You can safely ignore those warnings for a package if they do not occur for all channels you are using (including the default channels).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
When enabling the manager, you will get _Package Lookup Warnings_ for all packages that are not present in all channels. This is, again, due to renovate not having a concept of conda channels and treating each package for each channel as a separate dependency. You can safely ignore those warnings for a package if they do not occur for all channels you are using (including the default channels).
When enabling the manager, you will get _Package Lookup Warnings_ for all packages that are not present in all channels.
This is, again, due to Renovate not having a concept of conda channels and treating each package for each channel as a separate dependency.
You can safely ignore those warnings for a package if they do not occur for all channels you are using (including the default channels).


**Limitations**

The `conda` manager only supports a subset of the conda environment.yml specification. The following limitations exist:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The `conda` manager only supports a subset of the conda environment.yml specification. The following limitations exist:
The `conda` manager only supports a subset of the conda `environment.yml` specification.
The following limitations exist:

Comment on lines +13 to +17
- Only [release versions](https://docs.conda.io/projects/conda/en/latest/user-guide/concepts/pkg-specs.html#supported-version-strings) that are strictly semantically versioned are supported (e.g. `2.1.5`, but not `3.1.7.6`).
- The default `msys2` channel for Windows is not added when using default channels as renovate does not know which operating system you will use the `environment.yml` file with. If you use Windows, you will have to explicitly include the `msys2` channel to get all updates.
- key-value arguments in dependency specifications are not supported.
- The key `pip` in the `dependencies` list is ignored if it is a list.
- There is no support for the nonstandard keys introduced by [conda-lock](https://github.com/conda-incubator/conda-lock).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Only [release versions](https://docs.conda.io/projects/conda/en/latest/user-guide/concepts/pkg-specs.html#supported-version-strings) that are strictly semantically versioned are supported (e.g. `2.1.5`, but not `3.1.7.6`).
- The default `msys2` channel for Windows is not added when using default channels as renovate does not know which operating system you will use the `environment.yml` file with. If you use Windows, you will have to explicitly include the `msys2` channel to get all updates.
- key-value arguments in dependency specifications are not supported.
- The key `pip` in the `dependencies` list is ignored if it is a list.
- There is no support for the nonstandard keys introduced by [conda-lock](https://github.com/conda-incubator/conda-lock).
- Only [release versions](https://docs.conda.io/projects/conda/en/latest/user-guide/concepts/pkg-specs.html#supported-version-strings) that are strictly semantically versioned are supported. For example: `2.1.5` is supported but `3.1.7.6` is not
- The default `msys2` channel for Windows is not added when using default channels as Renovate doesn't know which operating system you will use the `environment.yml` file with. If you use Windows, you will have to explicitly include the `msys2` channel to get all updates
- key-value arguments in dependency specifications are not supported
- The key `pip` in the `dependencies` list is ignored if it is a list
- Renovate doesn't support the non-standard keys introduced by [conda-lock](https://github.com/conda-incubator/conda-lock)

Changes:

  • Drop . at the end of list items to match the style in the rest of the docs
  • Rewrite some sentences
  • Small grammar/typo fixes

@rarkins
Copy link
Collaborator

rarkins commented Jun 18, 2023

@morremeyer let's close this after 6 months inactivity. Of course, hopeful you can reopen or replace it soon :)

@rarkins rarkins closed this Jun 18, 2023
@morremeyer
Copy link
Contributor Author

@rarkins Good call, yes. I hope we can get to work on this again soon.

We definitely already have a much better idea of how to go about implementing it better than this first attempt.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 20, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants