Closed jamesmyatt closed 6 months ago
Name | Link |
---|---|
Latest commit | ee0b739557c66a84b4119506721cfaa9de6e1335 |
Latest deploy log | https://app.netlify.com/sites/conda-lock/deploys/65809a19086f9700084f4237 |
Deploy Preview | https://deploy-preview-573--conda-lock.netlify.app |
Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site configuration.
In this case it seems to me like Conda is using inconsistent indentation, no? The indentation level under channels:
and dependencies:
is 2 spaces, but the indentation level under pip:
is 4 spaces.
Wouldn't it make more sense to open the dual issue in Conda?
Thanks @maresb . Conda has used this formatting since always. I can't see them changing it, especially since it's just part of the ruamel.yaml configuration (parser.indent(mapping=2, offset=2, sequence=4)
) and there's no custom code for it. So it's 100% consistent with those settings.
In contrast, conda-lock is much newer and uses a custom serializer for environment files, even if it's super simple.
But regardless, for me, one of the main use cases for the conda-lock render -k env
option is to be able to compare it with the conda env export
output. So I think it makes sense to match the formatting as closely as possible. But minor differences in whitespace are not a dealbreaker.
It's also a (minor) inconvenience if you want to write some code to modify an environment.yml file that you'll end up with whitespace differences between a conda-env-produced one and a conda-lock-produced one.
Actually, I think the issue is that the pip dependencies actually should be an level 3 indentation, since it's mapping-sequence-mapping-sequence
e.g. data["dependencies"][-1]["pip"][n]
, not a level 2 one for data["dependencies"][-1][n]
. I'll experiment with some ruamel.yaml settings to see what might reproduce the conda-lock style.
Update: This isn't quite right. See below.
The ruamel docs describes yaml.indent(mapping=2, sequence=4, offset=2)
as "often seen" and says "It is best to always have sequence >= offset + 2". The "sequence" indentation is counted to the beginning of the sequence element and the "offset" is the indentation of the dash within the space defined by "sequence".
As far as I can tell ruamel.yaml calculates the indentation as follows ("mapping" doesn't seem to have an impact):
name: lock-test
channels:
- conda-forge
- nodefaults
dependencies:
- python =3.12
- pip:
- click
-> offset
---> sequence
-> offset
---> sequence
So when you're looking at the indentation of the sequences (via ruamel.yaml), you need to look at the position of the values rather than the -
. This makes "conda-lock" style with the conda dependencies indented by 4 spaces and the pip dependencies indented by 2 more, which is inconsistent with how ruamel.yaml calculates indentations. Different parsers like PyYAML may calculate this differently.
You can get the same effect using yaml.indent(mapping=2, offset=2, sequence=2)
, but only because the mapping for the pip dependencies only has a single value.
Thanks @jamesmyatt for all the research into this issue. This still looks weird to me, but if it's correct in some sense, and if it's more consistent with Conda then let's do it.
Just to confirm before merging, is this PR still correct in the sense of your last comment?
Yes. I'm happy with this.
If it helps, I think you can to look at it this way:
dependencies:
- python # <-- this dash is indented 2 spaces compared with the start of "dependencies:"
- pip:
- click # <-- this dash is indented 0 spaces compared with the start of "pip:"
Thanks for spelling it out @jamesmyatt, I get it now.
This is a minor change but it synchronizes the indentation of the pip dependencies with the output of
conda env export
. It makes it easier to compareconda-lock
env files with exports of real conda environments.Indentation in
conda env export
is determined by theruamel.yaml
configuration inconda.common.serialize
: e.g. https://github.com/conda/conda/blob/ff330a1807d34870e60a9b8d3540695587845296/conda/common/serialize.py#L20.Commands
environment.yml
conda-win-64.lock.yml
environment.yml