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

A few renaming suggestions #106

Closed
mnlevy1981 opened this issue Jun 12, 2024 · 4 comments · Fixed by #156
Closed

A few renaming suggestions #106

mnlevy1981 opened this issue Jun 12, 2024 · 4 comments · Fixed by #156
Labels
enhancement New feature or request

Comments

@mnlevy1981
Copy link
Collaborator

  1. What if we renamed cupid-dev -> cupid-infrastructure? Then we can talk about differentiating between the infrastructure to run CUPiD and the analysis done by CUPiD (non-developers still need to install this environment to use CUPiD)
  2. What if we renamed cupid-build -> cupid-publish? I'm trying to think of a better verb for creating a website, since build is often associated with compiling code. Or we could add a --make-html flag to cupid-run and get rid of cupid-build altogether. It's not clear to me that we really need separate commands; if you run cupid-run and then realize you want HTML output, cupid-run --make-html will notice that the notebooks are up-to-date and won't try to re-run them.
@TeaganKing
Copy link
Collaborator

I agree that the cupid-dev naming should be reconsidered. I think cupid-infrastructure could be a good option. I'm also wondering if something to specify that this is the environment which you run from, or even also calling the environment cupid-run could be helpful? Although we do also run cupid-build from that environment, too.

If we added a --make-html flag, I'm wondering how we would know that the notebooks are up-to-date? Eg, would we log the configuration information along with running cupid?

@mnlevy1981
Copy link
Collaborator Author

Maybe cupid-executables for the environment? Although I could see cupid-run being the right choice for the environment if we only provided a single executable for all functions (maybe we'd call that executable cupid without any hyphenated modifier?)

For --make-html, I was just thinking that if you run cupid-run twice in a row the second execution would be much faster because it would realize the notebooks are already up-to-date... I'm not actually sure how that happens (maybe something in ploomber), I've just noticed it when I've run through examples.

@TeaganKing
Copy link
Collaborator

I do think cupid-run would be easier to type than cupid-executables, and I would support just calling the executable cupid.

Ah, right! And if we expect users to run the notebooks and then immediately run the 'build' bit, would it make more sense to have the default be to make html after notebooks are run, and have a flag option for --skip-html?

@TeaganKing TeaganKing added the enhancement New feature or request label Jul 23, 2024
@TeaganKing
Copy link
Collaborator

Perhaps slightly tangential but still relevant, in #118 Mike suggested that we "clean up the names of the directories cupid-run creates -- maybe CUPiD_out/ with computed_notebooks/, computed_scripts/ (once we finish #93), and html/ (created by cupid-build rather than cupid-run)." We could make these modifications at the same time as the aforementioned renaming suggestions.

@TeaganKing TeaganKing linked a pull request Nov 21, 2024 that will close this issue
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants