Alias for CircleCI snap

Store URL:
Aliases requested: circleci

I am an upstream committer.

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.

The alias request makes sense to me, but why is the snap named circleci-local-cli instead of simply circleci? Then you wouldn’t need an alias.

I explained it in the last paragraph:

Do those newer tools need to be in separate snaps? Eg:

name: circleci
  circlieci: # today's tool
  future1: # future tool
  way-out-future: # another future tool

Again, I’m not against the alias per se, just wondering if there is something that might work better.

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:


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.

+1 for the alias

+1 to the alias from me as well.

@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.

Well as we all know, naming is hard.

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.

1 Like

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. :thinking:

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.

Let us know which way you’d like to go.

I already deleted the original snap. Thanks though.