New package: BayesianInference v0.1.0
- Registering package: BayesianInference
- Repository: https://github.com/BGN-for-ASNA/BayesianInference.jl
- Created by: @SebastianSosa
- Version: v0.1.0
- Commit: d046b396e6ef5b490a61908a125c416d365ae771
- Reviewed by: @SebastianSosa
- Reference: https://github.com/BGN-for-ASNA/BayesianInference.jl/commit/d046b396e6ef5b490a61908a125c416d365ae771#commitcomment-172947979
- Description: BI for Julia
Hi, congrats on the package! I would strongly recommend a less generic name, especially for a package that looks rather modest in scale (which means it cannot claim to represent all of Bayesian inference)
Also, if I'm not mistaken there is a lot of type piracy
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.
Hi, congrats on the package! I would strongly recommend a less generic name, especially for a package that looks rather modest in scale (which means it cannot claim to represent all of Bayesian inference)
Unfortunately, the name cannot be changed. It must remain consistent across the Python and R versions, and it is also the name used in the submitted paper.
Also, if I'm not mistaken there is a lot of type piracy
Indeed there is. The sole purpose of this is to enable basic, direct mathematical operations on JAX arrays, thereby preventing Julia users from having to convert those arrays manually.
Hi, congrats on the package! I would strongly recommend a less generic name, especially for a package that looks rather modest in scale (which means it cannot claim to represent all of Bayesian inference)
What about changing the package name to BIJ? Would that be acceptable, or is the name too uninformative?
it is also the name used in the submitted paper.
As a general rule, that is not something we can take into account for registrations, unfortunately. Always register a package before publishing about it. I have no opinion on whether the current name is appropriate or not.
What about changing the package name to BIJ
Three-letter package names are no longer accepted for new packages, so that is not an option.
Also, if I'm not mistaken there is a lot of type piracy
Indeed there is.
I would be extremely skeptical of registering any package that commits type piracy. There may be exceptional circumstances where this could be okay, but IMO it would have to have substantial community consensus that that is indeed the best / only way to solve a particular problem, and that the potential issues associated with type piracy (invalidations, correctness issues) have been mitigated
There is no type piracy in src/BayesianInference.jl. All extended methods operate on types defined within the BayesianInference module (BIObject or InspectableFunction).
it is also the name used in the submitted paper.
As a general rule, that is not something we can take into account for registrations, unfortunately. Always register a package before publishing about it. I have no opinion on whether the current name is appropriate or not.
What about changing the package name to BIJ
Three-letter package names are no longer accepted for new packages, so that is not an option.
Also, if I'm not mistaken there is a lot of type piracy
Indeed there is.
I would be extremely skeptical of registering any package that commits type piracy. There may be exceptional circumstances where this could be okay, but IMO it would have to have substantial community consensus that that is indeed the best / only way to solve a particular problem, and that the potential issues associated with type piracy (invalidations, correctness issues) have been mitigated
All instances of type piracy have been removed from src/BayesianInference.jl. Extended methods now only operate on types defined within this package (namely BIObject and InspectableFunction).
This resolves potential method conflicts and ensures the code adheres to Julia’s best practices for method extension without impacting unrelated code. docs.julialang.org
Regarding the package name: if the registry reviewers identify any issues with the name BayesianInference (e.g., similarity to existing packages or other naming concerns), I am happy to discuss possible alternatives. Otherwise, I believe the name reflects the domain and functionality of the package clearly.
Thanks for making the piracy fixes.
As for the name, it is too generic for what remains a very small wrapper package. If readers casually browse the registry, they risk thinking that this package is the reference for Bayesian inference in Julia, which is simply not true (I'd point to Turing instead).
For instance, PyBayesianInference would better reflect the fact that it is Python-based
For instance, PyBayesianInference would better reflect the fact that it is Python-based
Following your feedback regarding the generic nature of “BayesianInference,” I would like to propose a list of alternative names for my package, ordered by preference:
BayesInference – Shorter and still clear, though I understand it may still appear somewhat generic.
BayesianInterface – Emphasizes the package’s role as a lightweight wrapper or interface for Bayesian workflows.
BayesianIntegration – Highlights its ability to integrate functionality across languages and platforms.
BayesianInvestigation – Suggests exploratory or diagnostic tools for Bayesian workflows.
BayesInterface – A slightly shorter alternative to “BayesianInterface,” still clear and approachable.
The goal of these names is to clearly indicate that this is a helper/wrapper package, not a full-featured Bayesian inference framework like Turing.jl.
I would be happy to receive any further suggestions or guidance to ensure the chosen name aligns with Julia registry standards.
Thank you for your time and consideration.
Best regards,
Sebastian Sosa
Hi, thank you for the contribution to the Julia ecosystem. For the purpose of the package, I find that all of the alternatives you have suggested are too general. Specifically, the names don't reflect the fact that the package is a wrapper for a Python library. It would have been fine if the Python library itself were well known, e.g., Pyro, Torch, Tensorflow, XGBoost, and so on, which is unfortunately not the case. Most people probably won't be able to deduce that by reading BayesianInference, BayesInterface, BayesIntegration, BayesInvestigation, or BayesInterface.
Adding Python or Py or Pyro in the name would be beneficial
Adding
PythonorPyorPyroin the name would be beneficial
Would pyBayesianInference be suitable, then?
It was my first suggestion (with a capital P), so I won't veto it
PyBayesianInference seems good to me. Starting with an uppercase letter is mandatory for Julia packages
Closing in favor of https://github.com/JuliaRegistries/General/pull/144679