Utilities namespace
zimme opened this issue · 8 comments
Hey @SachaG
What's the plan for the utilities namespace?
I see you've published the avatar package under the namespace.
Should we use it for any general purpose utility?
Yeah, I did. I was hoping to get 2-3 other packages published under the namespace before making any kind of official announcement.
Just to bring people here up to speed: inspired by the talks of a collections organization, I created a utilities organization for things like the avatar package, spinner package, etc.
The problem with names like sacha:spin is that it makes it harder for others to contribute: they won't have publish rights for Atmosphere, so if they want to fork the package and take over they'll have to publish their own myname:spin package, forcing end users to change their code.
So by using the utilities:spin naming, we can ensure that users never have to change the name of the package in their code, and also that there's a small community of trusted developers who all have publish rights on each other's packages.
Yeah, pretty much in the same lines as I was thinking about the collections namespace.
Just a note. You have the option as a maintainer of a package, say sacha:spin, to add another meteor account as a maintainer to the package under the same name, which makes it possible for another person to publish under that package name.
But still it's a nice initiative, I just hope I'll get access to the collections namespace... otherwise I'll consider using this namespace maybe?
Oh yeah, I know I can add other maintainers. But the situation that prompted me to create utilities was that the maintainer for a package I use simply stopped answering emails or issues, so he wasn't able to add me.
Yeah, I get it. I've been there too 😝
So do you have any thoughts on if we're going to try and work out of some Github organization or just from our own repos?
My first thought is that it would be nice to work out if MeteorCommunity or MeteorDevelopmentCommunity or something, I feel MeteorPackaging is more for the 3rd party library effort.
This also relates to #72, where i suggested MeteorCollections. Now with this initiative I feel that working out of a common Github org might me nice.
I'm also sitting on the mdc namespace, short for Meteor Development Community
I'm fine either way. A GitHub org would make sense, but I think it'll be easier to start with letting people keep their existing repo if they want to.
I don't really have much thoughts on his point to be honest. The main problem I'd like to fix is end users having to change their .packages file when the package's maintainer changes.
That doesn't really make any sense to me. I feel like packages should have a unique name, and as a package author I should be able to transfer my package to somebody else without any extra work on the user's part.