But even then, this would have become an issue as soon as someone registered that user on GitHub. So, checking before creating a namespace would have been by no means a guarantee that there is no conflict.
I agree. The only way to be certain the namespace had no conflicts would be for the role author to secure the user or org on github first.
Previously, namespaces did always override GitHub users. And namespaces would only be created if a GitHub user hadn’t already claimed that name. There was no conflict. Whoever claimed a name on Galaxy first owned it.
Yes, I agree that was the case. We haven’t eliminated that behavior in new galaxy, but I feel that we shouldn’t continue to encourage it. What I’d personally like is to make custom namespace creation a self-service option within the UI, but we have to figure out what constraints to put on that to reduce “domain squatting” and other conflicts of interest. I’m open to suggestions on the best way to implement and constrain this as a feature.
This changed only with the new version of Galaxy. Saying that the specific namespace name was always problematic isn’t really fair. It was just fine with the old system. It only became a problem now.
I agree it wasn’t an obvious user facing problem previously, but it was a problem with self-service. Knowing to go to github to file an issue to ask for a custom namespace was a barrier to entry that most people wouldn’t know how to get around. For the backend admins, it was additional triage and work to process and fulfill those requests.
Sorry if my frustration is bleeding through… For us this change just was very surprising and caused quite a bit of a headache for many people. Contacting namespace owner in advance and letting them know would have been great.
It’s okay to be frustrated and I understand. We did our best to limit the frustration with the feature set we had time to deliver by the deadline and have been working around the clock to fix and re-add what we can. The whole team and organization has been taking all the feedback on this forum and coding as fast as possible to implement what is actionable.
Even now, I’m still not quite sure what the status of the old(?) namespaces will be in the future. Will we still be able to use them?
It’s “grandfathered” in at this point, so it’s not going away unless you or another authorized user for the namespace decide to delete it.
Can we continue to use them to combine roles from different GitHub organizations?
I’m not sure I fully understand what you are asking. Are you wanting to know if you’ll always be able to import into a namespace from an arbitrary / unmatched github_user value? If so, yes the current roles as is should continue to map into the right place. New roles though are a challenge because we don’t have a way to override the namespace at import time via the CLI or the API. I think we need to take that on as a feature request and get it done soon. I’ve noticed people have been putting a “namespace” field in their role’s meta/main.yml (maybe because of ansible-lint’s suggestion?), and I’m thinking that might be a good way to facilitate the destination namespace for an import without altering the REST api signatures or the CLI arguments.
The UI for this seems to be completely gone?
If that’s in reference to importing direct to a namespace, then yes it’s gone (for now). We’re rebuilding the foundations in the API and UI that should make this possible again in the future.
