JuliaRegistries
New package: FuseUtils v1.1.1
- Registering package: FuseUtils
- Repository: https://github.com/ProjectTorreyPines/FuseUtils.jl
- Created by: @orso82
- Version: v1.1.1
- Commit: 78a47619b01598569c291e1942a71a46bf54c371
- Reviewed by: @orso82
- Reference: https://github.com/ProjectTorreyPines/FuseUtils.jl/commit/78a47619b01598569c291e1942a71a46bf54c371#commitcomment-144862560
- Description: low-level utilities for FUSE ecosystem
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.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Just a suggestion – more descriptive name could be helpful for clarity. "Fuse" tend to be associated with the filesystem, as in https://juliahub.com/ui/Packages/General/FuseApi.
I'd definitely associate "Fuse" with the filesystem.
I was too late to comment on https://github.com/JuliaRegistries/General/pull/112083, but that package mentions "Basic data dictionary functionalities of IMAS.jl", but as far as I can tell, IMAS.jl does not exist. Is IMAS.jl planned to be released in the near future?
If so, and if this package is intended as another sub-package/dependency of IMAS, maybe IMASFuseUtils would be a sufficiently distinctive name.
When you say "other packages in the FUSE ecosystem", that should be a link to that ecosystem.
[noblock]
@aplavin @goerz indeed we're planning on registering IMAS.jl as well, since we have just made the package public. We want to first register the packages that IMAS.jl depends on, FuseUtils.jl being one of them.
This is part of a broader effort to open-source the FUSE framework that was developed by General Atomics. FUSE is a framework for design and optimization of nuclear fusion power reactors. It was recently presented at JuliaCon 2024 https://youtu.be/HCSdOMnzcnY?t=18425
[noblock]
FUSE.jl is a relatively big project. Developed over the past three years, it currently spans 25 repositories and over 200k lines of Julia code. All this to say that there will be lots of FUSE related packages coming down the line. [noblock]
https://github.com/JuliaRegistries/General/pull/112171#event-13751973915 just got merged [noblock]
@aplavin @goerz if this is ok, could you please proceed with the merging of this PR? Once this is merged, we can then proceed to register the IMAS.jl package. Thank you. [noblock]
[noblock] I don’t have manual merge permissions. The automatic merge will proceed when all comments have [noblock]
[noblock] ping @aplavin if it's possible to please add [noblock] to your initial comment https://github.com/JuliaRegistries/General/pull/112133#issuecomment-2260940462
Thank you!
I'd really like to stick to the current naming convention. This is what makes sense for us.
Googling FUSE at this point will certainly return few fusion-related results since we are in fact trying to open-source our project and make it easily findable by registering it on the General registry.
@aplavin if you could add [noblock] that would be great! Thank you in advance.
On technical grounds, I don't see a reason not to merge this.
However, the mentioned name conflict with the Fuse filesystem is unfortunate. Especially as it seems that you don't want to register only FUSE.jl but an ecosystem of FuseX.jl named packages. Even a FuseFS.jl or FuseAPI.jl could then be confused with your ecosystem. How many FuseX.jl do you plan to register?
Also note that it's generally better to release the main package as soon as possible when registering ecosystem packages. The reason is simple: who says that after registering your FuseX.jl packages the name FUSE.jl is still available?
It seems to me that "GA" (for General Atomics) is a distinctive and "established" prefix that could be considered here, at least for the ecosystem packages (I.e dependencies of FUSE.jl). But I'm not an expert on the topic.
Thank you for the comments @carstenbauer.
Unfortunately I don't see a way to register the main package as soon as possible if I cannot register its dependencies first. Are you suggesting to make an empty package with the desired name, and push that through the registration process first? Wouldn't that raise concerns about people holding onto package names without actually using them?
We are open sourcing our software and releasing it to the public so that this can become a platform for the fusion community to build on. Branding it as GA goes agains this idea. Like say Oceananigans.jl is not called MITOceananigans.jl.
Here's the documentation page for FUSE https://fuse.help and repo https://github.com/ProjectTorreyPines/FUSE.jl
We are open sourcing our software and releasing it to the public so that this can become a platform for the fusion community to build on. Branding it as GA goes agains this idea. Like say Oceananigans.jl is not called MITOceananigans.jl.
I wasn't suggesting a rename FUSE.jl -> GAFUSE.jl but was talking about its dependencies, specifically those that are named FuseXYZ.jl. I'm fine with FUSE.jl. It seems to be a cool, serious effort, you are the first to occupy the name, and I understand that it's an adequate, catchy name for a bigger project. The fact that FUSE is ambiguous is unfortunate but acceptable, IMO. What I was wondering is whether we can find a better naming compromise for dependencies like FuseUtils.jl, which could also be confused with FUSE (the file system / kernel module) utilities.
Looking at the FUSE.jl repo, it seems like FuseUtils.jl is the only "problematic" dependency. Would it be possible to rename FuseUtils.jl to something less generic and less ambiguous?
(UPDATE: I see that there also is FuseExchangeProtocol.jl in General...)
Unfortunately I don't see a way to register the main package as soon as possible if I cannot register its dependencies first. Are you suggesting to make an empty package with the desired name, and push that through the registration process first? Wouldn't that raise concerns about people holding onto package names without actually using them?
Sorry, this was merely meant as advice to try to be as quick as possible (perhaps stating the obvious). But to be concrete, I would perhaps think about already opening a (draft) PR for registering FUSE.jl (not an empty repo) to indicate my intentions.
Thank you for the clarifications @carstenbauer
We can rename FuseUtils something else. That's not the end of the world. But do you think anything starting with Fuse would be always unacceptable? What about if the packages started with FUSE all capital, likeFUSEutils. I don't like it but oh well.
I'll follow your suggestion and open a PR for the main package even if it will fail because of the dependencies not being registered.
But do you think anything starting with
Fusewould be always unacceptable?
No, I wouldn't make a blanket statement like this. I think FuseUtils.jl is particularly unfortunate because Utils is very generic and doesn't disambiguate at all. For example, "FuseReactor.jl" can hardly be (mis)associated with the FUSE file system.
What about if the packages started with
FUSEall capital, likeFUSEutils.
No, I don't think this helps (and I also don't like it 😉).
In any case, it would be good to get a comment from @DilumAluthge (or someone else) here as well.
[noblock] Just my opinion: I think we should give FUSE.jl in particular a pass, given how fully developed it is. And Julia is a language for scientific computing, so having a particularly nice fusion-related package called FUSE seems okay, even if it's not about the possibly more widely understood "Filesystem in Userspace".
While FUSE.jl can't be registered without its dependencies being registered first, that package will require a manual merge anyway (uppercase name rule), so I don't think we'll run into a situation where someone else will register FUSE.jl without anyone noticing. Another option would be to prepare a manual PR to register the entire FUSE ecosystem in one go (FUSE.jl and all its currently unregistered dependencies).
As for "sub-packages" like FuseUtils: My general opinion is that an existing MyPackage "owns" the namespace for MyPackageSomething packages. In this case, that would be FUSEUtils (with an uppercase FUSE, and I'm not a fan of deviating from CamelCase by making the U in Utils lower-case). Using FuseUtils already deviates from this (case-sensitive) scheme, where the package name is "obviously" connected to FUSE.jl. So at that point it might be better to go with FusionUtils. But I'm not super opposed to FuseUtils either. However, since Fuse/FUSE is such an overloaded name, I don't think it would be fair for FUSE.jl to completely own the FuseSomething namespace. It'll have to co-exist with other packages related, e.g., to the filesystem FUSE. It's not an ideal situation, but probably tolerable.
Ok. Thank you for the feedback. Let me regroup with my team and figure out the best way forward and how we can minimize collisions with FuseWhatever.jl packages. We may indeed follow up on the open a manual PR to register the whole FUSE ecosystem in one go.
This PR can be closed
https://github.com/JuliaRegistries/General/pull/119445