Reasoning: Currently, the tool is not really packaged at all and the snap will be the first packaging of it. We currently have users install it as the circleci command this for backwards compatibility (and honestly, vanity), I’d like users to continue to be able to use circleci rather than circleci-local-cli.circleci.
The reason for not naming the snap itself as circleci is that there will be one, maybe two snaps/tools coming from us in the future. Using circleci- as a prefix for our snaps helps with organization.
I mean, the technical answer is likely no, they don’t need to be in separate snaps. Problem is, they are different projects, versioned differently, used for different reasons and for one of the tools, a different customer than what this local CLI would be used for.
My plan was to then use 3 different ones so that each team has control over their own codebase and release cadence.
Something like:
circleci-local-cli
circleci-tool2
circleci-tool3
I could easily name the first snap, this one, circleci however my concern is when searching in the Snapcraft Store, or via the CLI, the ambiguity between each tool.
Ok. Snaps are a different paradigm than other packaging methods and wanted to make sure all the options were explored. If all these tools were from the same project or needed to call each other, that would suggest them being in the same snap. You’ve indicated a clear and reasonable preference for having them separate.
@FelicianoTech How are the other tools named? I mean, the actual command line you’d like people to use?
It does sound to me that given the name of the tool, the most natural way to name it is indeed just circleci. This seems extremely natural, for example:
$ snap install circleci
$ circleci --help
Otherwise it’s one extra step that people just need to know.
When people do snap find, it should list any snaps with circleci as a prefix, and also circleci proper.
With that said, it’s a recommendation. If you feel strongly about the alias, the prefix provides good enough context.
One tool already has a name, using circleci as a prefix similar to this tool. It’s not public which is why I haven’t given its name.
The third tool, which doesn’t exists yet, will also be a CLI. It might have some overlap with this tool in terms of purpose but will be an entirely different codebase. I don’t even know what the command would be yet for that and it’s likely not my decision internally. If anything was to just have the package name circleci, it would be this third tool but it doesn’t exists yet.
Now, I could have this snap called circleci and when the third tool, a CLI comes out, replace the codebase with the new one. The problem there is, there’s no guarantee at this point that there will be backwards compatibility. I don’t want to push a major codebase change, essentially a brand new project, to the same snap and break usage for existing users.
I’m going crazy here. On the other hand, it looks like with the process I’ve laid out, I’d have to go through this Alias Request process for each snap we put out?
That’s not ideal at all, especially with the 7 day period.
This manual process is a real turn off, especially for someone coming from a CI background.
I’m going to cancel this Alias Request for now, so I can proceed with everything else I’m doing around this and think about naming and the CLIs later on.
It doesn’t have to wait 7 days if we have enough consensus. And if you want the alias, it’s certainly fine since the scope leaves no room for confusion with something unrelated.
The store workflow is similar to that of CI, except when it requires touching on global namespaces or security, which are cases that require just a little bit of coordination.
