New package: QuantDynSim v0.1.0

[JuliaRegistrator]

• Registering package: QuantDynSim
• Repository: https://github.com/amartyabose/QuantDynSim.jl
• Created by: @amartyabose
• Version: v0.1.0
• Commit: 1cba93106f30ed6e19110975fcede23e6017ddd6
• Reviewed by: @amartyabose
• Reference: https://github.com/amartyabose/QuantDynSim.jl/commit/1cba93106f30ed6e19110975fcede23e6017ddd6#commitcomment-147870760
• Description: Simulations using QuantumDynamics.jl made a breeze

[github-actions[bot]]

Hello, I am an automated registration bot. I help manage the registration process by checking your registration against a set of AutoMerge guidelines. If all these guidelines are met, this pull request will be merged automatically, completing your registration. It is strongly recommended to follow the guidelines, since otherwise the pull request needs to be manually reviewed and merged by a human.

1. New package registration

Please make sure that you have read the package naming guidelines.

2. AutoMerge Guidelines are all met! ✅

Your new package registration met all of the guidelines for auto-merging and is scheduled to be merged when the mandatory waiting period (3 days) has elapsed.

3. To pause or stop registration

If you want to prevent this pull request from being auto-merged, simply leave a comment. If you want to post a comment without blocking auto-merging, you must include the text [noblock] in your comment.

Tip: You can edit blocking comments to add [noblock] in order to unblock auto-merging.

[goerz]

Is there any way this can just be a part of QuantumDynamics? Presumably, you could put it in a QuantumDynamics.CLI submodule.

@Roger-luo Any suggestions on how to set up a package that's mainly intended as a normal Julia library, but has an optional CLI component? Glancing at the documentation, it seems to me that it would be sufficient to just not write a build.jl file. Then, users of QuantumDynamics can install the CLI utilities on demand by running, e.g.,

QuantumDynamics.CLI.comonicon_install()

in the REPL.

If, for some reason, it is not possible to keep this as part of QuantumDynamics, I would request QuantumDynamicsCLI as a package name. I would also ask to add more documentation (in the README) in this case. Give some context and a usage example, explain when and where the qdsym executable script is installed, probably show the output of qdsym --help.

Of course, if it's part of QuantumDynamics, you'll also want to properly document the script in that package's documentation.

[Roger-luo]

[noblock]

well it's possible wtih https://github.com/JuliaLang/Pkg.jl/pull/3772 maybe. but only possible with the cost letting the package depends on Comonicon at the moment. or if you want to pay a bit overhead to write some wrapper code inside the package, you can also make this a package extension.

[goerz]

That's a good point! I'm a big fan of trying to avoid unnecessary or optional dependencies. Thus, I'd definitely support this under the name QuantumDynamicsCLI as a straightforward solution

[amartyabose]

Hello,

What would you suggest is the best course of action right now? This package basically creates a CLI command for doing simulations with the most common (and growing) set of algorithms that are present in the QuantumDynamics.jl package. Should I rename it to QuantumDynamicsCLI.jl or would it be better to do package it inside the QuantumDynamics.jl package itself as @goerz suggested?

@Roger-luo , could you help me with the App support bit? I really like this idea though I am new to this…

[goerz]

If I were you, I would just rename to QuantumDynamicsCLI, add some more documentation to the README, and re-register. Not having to add Comonicon as a dependency to QuantumDynamics is a good argument for not having the CLI tools in QuantumDynamics directly.

If you can come up with a creative solution that involves a package extension, that could be an interesting learning experience. But objectively, I'm not sure if it's worth it.

[amartyabose]

If I were you, I would just rename to QuantumDynamicsCLI, add some more documentation to the README, and re-register. Not having to add Comonicon as a dependency to QuantumDynamics is a good argument for not having the CLI tools in QuantumDynamics directly.

If you can come up with a creative solution that involves a package extension, that could be an interesting learning experience. But objectively, I'm not sure if it's worth it.

Thanks. I’m going to be out of office for the week. I’ll do this the next week and resubmit a package registration request.

[Roger-luo]

@Roger-luo , could you help me with the App support bit? I really like this idea though I am new to this…

no problem, feel free to ask about more specific issues under Comonicon (I might not have much time recently adding new features tho, but happy to answer anything that you think not clear.

[github-actions[bot]]

This pull request has been inactive for 30 days and will be automatically closed 7 days from now. If this pull request should not be closed, please either (1) fix the AutoMerge issues and re-trigger Registrator, which will automatically update the pull request, or (2) post a comment explaining why you would like this pull request to be manually merged. [noblock]

[github-actions[bot]]

This pull request has been inactive for more than 30 days and has automatically been closed. Feel free to register your package or version again once you fix the AutoMerge issues. [noblock]