#Auto PR and modules duplciation
1 messages · Page 1 of 1 (latest)
I get your point, and I agree that on certain scenarios it doesn't make sense. If you are thinking that it should be an opt-in feature, I also personally agree. I was just saying that alone it won't solve the issue
Sure, I think there are other enhancements we should also consider to spruce up the daggerverse; perhaps prioritising modules in the search which have tagged version rather than dev-main, having some sort of vendor/module convention to help sort out duplicates & forks, ability to sort by number of installs might also be helpful, but I don't know if daggerverse tracks this
@ornate moon FYI, I don't know if there is a roadmap already, but these sounds like cool things to have
@calm pecan don't you have "vendor" information already in the github URL shown in the search result boxes? It is only to make it evident or something else?
you kinda do; but for php packages on packagist; the vendor and package name are unrelated to the github url; it's purely based on what's in composer.json (for dagger, dagger.json) so if I made a module called carnage/helm and you made one called dciangot/helm, they'd be considered different packages; however if you forked my carnage/helm package they'd be seen as the same and your fork wouldn't be indexed. If you wanted to make the fork a package in it's own right, you'd change the vendor name to be your own and move forward separately, but that makes it a conscious decision rather than an automatic move.
the main reason you need the vendor for deduplication is that there could legitimately be two helm packages that work differently and it'd be really really annoying to require unique module names
cc @gritty pond also 🙏