-
Notifications
You must be signed in to change notification settings - Fork 13
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: Support updating conda recipe meta.yaml file #28
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It seems like this PR generates an entire |
vyasr
changed the title
Support updating conda recipe meta.yaml file
feat: Support updating conda recipe meta.yaml file
Dec 2, 2022
vyasr
added a commit
that referenced
this pull request
Mar 7, 2023
This PR adds support for in-place modification of pyproject.toml files. The modification cannot be done out of place in this case because only a subset of the file is dependencies and there is no way for a pyproject.toml file to point to another location for its dependencies. On the positive side, the changeset here is quite small and easily manageable. OTOH, there are a number of open design questions that should be addressed before merging this PR. Note that some of these considerations are the same as for conda meta.yaml files in #28. I would consider pyproject.toml to be the easier of the two and require solving a subset of the problems needed for meta.yaml. Essentially all of the problems below exist in similar form for those files, so figuring out how pyproject.toml support should look will get us a large part of the way towards enabling meta.yaml. 1. The interpretation of the `files` key of dependencies.yaml is somewhat suspect when used for pyproject.toml because there is no sensible reason to want to rename the file (this is also true for meta.yaml) 2. For the optional dependencies, we need a way to specify the key of the optional dependencies section. I am currently using the file name for this purpose, but this may be problematic because the file name may not be unique i.e. we might need optional test dependencies in pyproject.toml as well as a test_*.yaml env file (This same problem exists for meta.yaml due to the different host/build/run/test sections). Furthermore, I've currently hacked this in by passing the filename key into the `make_dependency_file` function even though that function doesn't need it for anything else because the output filename has already been generated and is one of the inputs here (this is also why one test is currently failing). If we move forward with this approach, that code will need a bit of refactoring. 3. I am currently splitting up the build requirements, the run dependencies, and the optional dependencies as different OutputTypes, which is functional but somewhat contrived as being distinct from the different sections in (2). **EDIT** The above concerns have mostly been addressed. We are now using a single output type for all pyproject sections and allowing a new `extras` section that can be used to provide data specific to pyproject.toml, in this case the table and key under which to store a particular dependency list. This addresses points 2 and 3 above. Point 1 is still somewhat unaddressed, but is mitigated by better documenting the behavior.
This approach is superseded by #45 |
difyrrwrzd
added a commit
to difyrrwrzd/dependency-file-generator
that referenced
this pull request
Aug 10, 2024
# [1.5.0](rapidsai/dependency-file-generator@v1.4.0...v1.5.0) (2023-03-07) ### Features * Add support for writing pyproject.toml files ([#33](rapidsai/dependency-file-generator#33)) ([65cd2b3](rapidsai/dependency-file-generator@65cd2b3)), closes [#28](rapidsai/dependency-file-generator#28)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds support for a new file type to the dependency file generator. The current implementation is really a POC and needs substantial improvements, but it's a good starting point for discussing where the current state of the package and what refactoring is needed to support more general use cases (many of the considerations for meta.yaml will also apply to pyproject.toml).