-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
Metapackage versions #733
Comments
Some packages like hubward and metaseq rely on non-Python tools like UCSC utils and bedtools that users may already have installed. If they don't already have them installed, the respective metapackage will set everything up. It's much more convenient to say "install the metapackage" than to describe how to download and install each individual moving part. Another possible reason is for aggregating tools of a specific type. One example we had talked about before was a metapackage for all bigBed-related tools from UCSC. In the end, they are more about convenience. As for versioning, I'm not sure. A UCSC bigBed-related metapackage should have the same version as all the UCSC utils included in the package, but it's not clear what to use for a metapackage tying together disparate tools. |
Ok, that makes a lot of sense. Exactly, metapackages that just represent a collection of arbitrary tools should maybe have their own versioning. We could recommend semantic versioning, starting from 1.0.0. |
Sounds good. I'll do a round of docs updates, including metapackage versioning and notes about building with perl-threading. |
Great, thanks! |
Maybe the guidelines should be GUIDELINES.md instead? Similar to README.md and so on... |
Yep, good point |
I noticed that we already have a couple of metapackages in Bioconda. My question is, what is their purpose, and how should we version them?
The text was updated successfully, but these errors were encountered: