-
-
Notifications
You must be signed in to change notification settings - Fork 3
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
Added pybamm-cookiecutter
CLI
#36
Conversation
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 looks nice, thanks, @santacodes! Since the files (for the models and the entry point handler) from the project have been removed, I think we can remove references to them from our bundled licenses (and add them to the generated project's bundled licenses if they are not present).
pybamm_cookiecutter
CLI pybamm-cookiecutter
CLI
Co-authored-by: Agriya Khetarpal <[email protected]>
@santacodes could you merge main here? |
I did merge it, I think the merge commit got hidden within the |
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 is looking good, thanks, @santacodes! Here are some of my suggestions besides the code review that are better provided in text:
- Installing and running it displays the message
No git tags found in template, using HEAD as ref
– this is marked in red, which might prompt users/newcomers to think that something is wrong. Is there a way to disable this message or make it clearer? That said, I don't think this is coming from any of our changes, though. - The CLI has a problem where it truncates long sentences, at least on macOS – I noticed that the sentence was terminated before completion as follows: "such as `import p"
- There's no option to go back if I made an error while typing things out – does
copier
support undo functionality? - I think we need better exception handling. If I terminate the program in between by pursuing a
KeyboardInterrupt
(Command + D on my machine), it prints out "Error caused by an exception:" followed by a long list of metadata that was being used to generate the project, stopped midway. Comparing this with thecopier
CLI, this is just "Execution stopped by user", which is more elegant. Also, Is there a way to distinguish a keyboard interrupt from an actual error? - Also, in the previous point, a keyboard interrupt midway into creating a project returns an exit code of 0, indicating success, instead of a non-zero exit code to indicate failure – I think it should be 0 for successful completion, 1 for an error in the project generation, and 2 for a keyboard interrupt, and higher for any other non-standard error.
Co-authored-by: Agriya Khetarpal <[email protected]>
I think this could be resolved by providing a
Could you please attach a screenshot of some kind it's hard for me to picture it 😅 .
I think it does not, looking at the documentation. Maybe I could try to come up with some kind of a hacky way to do it something like recording a particular keystroke for example
I agree with that, I will add better exception handling in the CLI and try to cover most of the endpoints.
For that, I think we could just wrap the exception handling to |
Also, if we were to run |
I think it might be a bad idea to use the |
I would say we should use what brings simpler code to write (and test) – my suggestion is not about handling |
Umm I think you misunderstood me, you should perhaps look at this copier CLI source code, but in brief, the CLI handles only three exceptions out of which 2 are copier specific errors which are already handled in the
And even the word trimmings you mentioned earlier shouldn't be much of an issue because they only get trimmed after a user answers the prompt if I am not wrong, I tested that locally as well. Overall, I think we should be good with handling the |
Thanks for the explanation and the cross-links to the code, @santacodes – makes sense to me! Yes, there's no need for extra abstractions, then. Please let us know when this is ready for review again. |
Co-authored-by: Agriya Khetarpal <[email protected]>
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.
Thanks, @santacodes! This looks really good. A couple of comments below -
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.
Thanks for working on this, looks amazing, @santacodes!
Good practice tip: You should revert the commit where an unwanted file (in this case -
_version.py
) was added instead of deleting the file in another commit. Adding and deleting the file still leaves it in the git history. We don't require reverting here as we will "squash and merge" the PR, so the git history within this PR will be lost anyways.
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.
Thanks @santacodes, a couple of comments below
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.
Thanks, @santacodes! I tested out the CLI exceptions and this looks good to go now. I do have one suggestion, so I'm not approving this at the moment – happy to do so once it's fixed. It's about license compliance (xref #43) – I built the sdist and wheel, and while both do contain the relevant LICENSE files, this is the content of the project's (pybamm-cookiecutter
's) bundled LICENSES file, which doesn't seem to make much sense:
$ cat LICENSES-bundled.txt
This project and source distributions bundle several libraries that are
compatibly licensed.
Name: PyBaMM
Files: - src/{{ project_slug }}/parameters/input/Chen2020.py
- src/{{ project_slug }}/models/input/BasicReservoir.py
- src/{{ project_slug }}/models/input/SPM.py
- src/{{ project_slug }}/entry_point.py
License: BSD-3-Clause
because pybamm-cookiecutter
doesn't contain these files anymore, and pybamm-cookiecutter
won't know about what {{ project_slug }}
represents either until a project is generated. This should be moved to the generated project's LICENSES-bundled.txt.jinja
file (which was outdated), since the generated project is where the files now exist. I think we can remove the LICENSES-bundled.txt
file from pybamm-cookiecutter
entirely, since we are now not using any third-party code.
Thanks, @santacodes! |
Additions
cli
with an optional--path
argument defining the path generated project should reside within.cli
usage incli.py
andREADME.md
.Removals
models
,entry points
, andparameter sets
from the project as they are now populated in the template.project-tests
fromnoxfile
and updated workflow to only test the template.pyproject.toml
andpybamm
as a dependency in the project.Usage
To test this, check out this branch and inside the repository and do a local
pipx
installation on your machine.After installation, the
CLI
will be available systemwide and can be accessed using thepybamm-cookiecutter
command.For help references add the
-h
or--help
flag, e.g.pybamm-cookiecutter --help
which would prompt with all the available arguments.Sub-task #26