-
Notifications
You must be signed in to change notification settings - Fork 104
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
Adding options to log addition additional metadata into the lockfile #204
Conversation
✅ Deploy Preview for conda-lock ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
Yeah having the metadata exist as a nice structured pydantic model with the various fields being Optional sounds great to me. When converting the model to raw python dictionary you can easily just exclude the fields with |
Not sure what to do about these timeouts in the tests, but it seems like the ubuntu test that failed in |
Can you add some tests to assert that the kind of metadata output we would want remains in the files. These kinds of regression tests are invaluable to ensure that conda-lock has minimal regressions over time. |
Absolutely. Just wanted to make sure that the approach looked reasonable to you before moving forward on writing tests. I'll try to get that done ASAP. |
I'm not really sure what's going on with the test that's failing. I didn't change anything related to the code for updating dependencies, and that test is failing for me locally when run on main as well. |
70173a3
to
e7c613c
Compare
@mariusvniekerk I think this is passing all CI except the test that seems to be failing on main / other branches as well. Happy to add more tests if you'd like, but if you wouldn't mind taking another look I'd really appreciate it. |
I landed #226 which should hopefully make the test suite here a bit more reliable |
@wolfv Would this change impact micromamba in any way? |
Let's ask @Klaim who implemented the lock-file handling in micromamba! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some nits with the formats and using md5 alone for the inputs metadata.
conda_lock/src_parser/__init__.py
Outdated
def create(cls) -> "TimeMeta": | ||
import time | ||
|
||
return cls(created_at=f"{time.asctime(time.gmtime(time.time()))}") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you use an ISO 8601 formatted value here instead of asctime
which is awkward to parse programmatically?
Hello!
New fields in "metadata" will be ignored by micromamba (assuming I didn't miss a bug), see details of the parsing in that function. It will only look for specific fields it needs. |
osx-64: d01c1f5433f30bdbcd3bdad8d9b096774ab55f1210c094acdc61a35b32b28d67 | ||
win-64: 310b23581083bfb983927c40d3bdc86162192d7b26ffd7bffc385f627c155697 | ||
inputs_metadata: | ||
/Users/c13371nroach/Documents/repos/conda-lock/tests/zlib/environment.yml: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should probably be a relative path not an absolute one
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think (and I will x2 check this) That it uses a relative path if provided a relative path when conda-lock is invoked, and an absolute one if passed an absolute path. Happy to make the path relative (perhaps to the lockfile?) if you think that's always preferable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that is generally preferable. Leaking in usernames etc into the lockfiles seems undesirable
Co-authored-by: Marius van Niekerk <marius.v.niekerk@gmail.com>
Co-authored-by: Jannis Leidel <jannis@leidel.info>
@mariusvniekerk @maresb |
Thanks! Let me review this quickly |
We probably don't need |
default=None, | ||
description="Metadata dealing with the input files used to create the lockfile", | ||
) | ||
custom_metadata: Optional[Dict[str, str]] = Field( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suppose I want to include something like environment.yml
which contains lists. Shall we make this a fully general dict?
(Needs from typing import Any
)
custom_metadata: Optional[Dict[str, str]] = Field( | |
custom_metadata: Optional[Dict[Any, Any]] = Field( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally not. It places a lot of extra strain on other implemations that make use of the file format like micromamba
. Any
is FAR too broad a type. I can potentially see value in a Union[str, list[str]]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. Ideally it would be some sort of recursive type like T: Union[int, str, list[T], dict[str,T]]
, but Pydantic chokes on that already.
Note how requirements
must be at least list[Union[str, dict[str, list[str]]]]
due to ["pip", {"pip": ["pypi-dep"]}]
. Thus to parse most requirements.txt
we'd need at least something like
dict[str, Union[str, list[Union[str, dict[str, list[str]]]]]]
(assuming I didn't make any mistakes).
Given the complexity, I've convinced myself that this should be a separate feature. But in this case, we should probably make it clear in the --help
that metadata-jsons/metadata-yamls contents must be dict[str,str]
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to support dict[str, Union[str, int, float]]
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I'm getting at here is, if we have
# md.yaml
x: a
y: 1
z: 1.5
is it correct to have the current result of conda-lock --metadata-yaml md.yaml
be as follows?
custom_metadata:
x: a
y: '1'
z: '1.5'
Perhaps that's the simplest since strings faithfully encode most reasonable types, and it prevents other potential headaches.
Co-authored-by: Ben Mares <services-git-throwaway1@tensorial.com>
In the near future someone may propose a command-line option to add a key-value pair to the custom metadata. Perhaps it should be called something like conda-lock --metadata git_sha --add-metadata short_git_sha=$(git rev-parse --short HEAD) Are we satisfied with using |
probably sufficient as the first draft. I want to make some tweaks to the models a little bit in a subsequent pr. And we can get the cli cleaned up in another one. |
Hello! thank you for making conda-lock, it's a great tool.
This PR would add the ability to specify extra comment lines into the lockfile as well as info about git repository etc. I added these metadata lines as a series of new flags:
--metadata
can be specified multiple times to request any of the individual metadata tags, as requested here:#204 (comment)