linode-cli
linode-cli copied to clipboard
linode
Provide linode-cli in the Linode APT repository
The deprecated github.com/linode/cli project was available through Linode's APT repository.
This issue is a place-holder for any decision to include or exclude linode-cli in the Linode APT repository.
I would prefer to not distribute the CLI through multiple channels.
There should be one-- and preferably only one --obvious way to do it. -- The Zen of Python
In my mind, pip is available on everything and is usually installed by default. I don't see a reason to complicate distribution of this tool.
That said, it is confusing that brew install linode-cli and apt-get install linode-cli and yum install linode-cli (and more) all install the wrong Linode CLI. We should address this, possibly by deprecating or outright removing those old packages. Your thoughts are welcome.
I think the argument in favor of using other distribution channels is that those channels are the default or most popular in those environments.
As such, those channels are the ones integrated with the operating environment, allowing individuals to search for all "linode" tools, and upgrade all tools (not just Linode or python tools) at once.
The value of being able to find "linode" tools in the packaging channel of the OS is that it acts as a marketplace. Linode users, and potential users, can find tools without being directed to them.
I've often discovered systems by "apt-cache search techname" and finding a suite of tools (a database, IDE, or web-server environment) that I hadn't heard of before. I don't want to use 3rd party installers on my otherwise pristine Ubuntu/Debian/Fedora system because everything else is in the OS repos, and this one installation will be the one I forget to monitor for security risks or otherwise update.
Additionally "apt-cache search cloud compute" (or perusing the Ubuntu Software Center) could be the way a new user discovers Linode.
I'm not sure people use their distro's package manager as the default way to find tools for their systems anymore - I know I don't. I don't brew search kafka to see what's available on OS X, for example - I google kafka and find their instructions. This is how I'd expect someone to find the Linode CLI, and (aside from the old and deprecated version) all of the top requests indicate that you should be installing it through pip.
Distributing through only one package manage also has the upside of making the installation instructions dead simple. This section is a problem, in my opinion, because I looked for installation instructions and found few pages where I expected a sentence. I don't want to have to think about this stuff, and it isn't necessary to make me. I much prefer the instructions present here.
I'm not sure people use their distro's package manager as the default way to find tools for their systems anymore - I know I don't. I don't brew search kafka to see what's available on OS X, for example - I google kafka and find their instructions. This is how I'd expect someone to find the Linode CLI, and (aside from the old and deprecated version) all of the top requests indicate that you should be installing it through pip.
I am with @Dorthu on this. I think we should maintain a pip package as our single, authoritative distribution. My philosophy when it comes to python is you use the distro's package manager to setup the python environment and pip and use use pip to manage the python packages in your virtual/global environments. This affords the sharpest separation of concerns. As long as we avoid native extensions in the CLI it should be portable to any distro with a working python 3.x environment independent of how it happens to be organized/installed(from package, built from source, etc.)
With that said I don't see any problem with coordinating and supporting volunteers that want to maintain unofficial packages for their favorite distros. https://www.linode.com/community/questions/139/what-license-is-the-new-linode-cli-released-under Someone from the Arch community is already doing this.
I'm with @displague. I think we should put it in any repos that we put the old version of the CLI in, ideally.
I see two references to people's personal philosophies/preferences which is pretty subjective. It's not like every Python dev buys into the Zen of Python or cares about pip or cares about what we think Python best practices are.
It's not really not uncommon/weird to install Python packages via upstream repos. I can think of many instances where we have done so.
I'm not sure using our own individual experiences to indicate what we should be doing is the way to go here. Personally I do use apt/pacman/brew for installing things, since it means the overhead of remembering what versions I have of software is (generally) not my concern. But that, like most things, is subjective; what matters is that these package managers exist along with a general expectation that people use them. Additionally, people who have used apt and friends to install the Linode CLI may be unpleasantly surprised to find out they have obsolete versions of the CLI which they now need to remove manually before reinstalling via another workflow.
Regarding pip specifically, the homepage for the project (link: https://pip.pypa.io/en/stable/) describes it as a method for installing Python packages, not OS or user tooling. I don't think it's reasonable for users to need to know or care what language(s) our tools are written in if their chief concern is using them as opposed to modifying them. If I want to spin up resources on Linode, doing so should be simple enough for a user that familiarity with their OS is sufficient: requiring that users are familiar with the internals of how Python manages packages only presents an unnecessary barrier.
[the CLI] should be portable to any distro with a working python 3.x environment
actually 2.7 or 3.x 😉
I see two references to people's personal philosophies/preferences which is pretty subjective.
That's fair, but I think I've made some more concrete points as well. Maintaining packages in more than one place is potentially error prone, and certainly more overhead. It also necessitates complicating install instructions by asking the user to decide what package manager they want to use and presenting them with a list of options, whereas with the current (and my preferred) method there is one and only one authoritative way to do it (and it works everywhere). I agree with @nsfyn55 that we should support third-party volunteers who want to package this elsewhere, but I don't see any benefit in having more than one official distribution. Comparing the old instructions with the new instructions, it seems obvious which is better.
(I'm not knocking the old CLI, by the way - there wasn't a better option for it. pip has the enormous benefit of coming preinstalled on nearly everything, being available for install on the rest of everything, and being widely used and supported for tools like this already. It even works on Windows I hear).
Additionally, people who have used apt and friends to install the Linode CLI may be unpleasantly surprised to find out they have obsolete versions of the CLI which they now need to remove manually before reinstalling via another workflow.
This is true, which is why I was suggesting removing those old packages entirely. It would be an even worse user experience to apt-get update && apt-get upgrade and suddenly get a new, incompatible CLI that even requires a different authentication mechanism from a new manager you may've never heard of before, especially if you find out about it because your automated scripts break after the upgrade.
Additionally, people who have used apt and friends to install the Linode CLI may be unpleasantly surprised to find out they have obsolete versions of the CLI which they now need to remove manually before reinstalling via another workflow.
It would be an even worse user experience to apt-get update && apt-get upgrade and suddenly get a new, incompatible CLI that even requires a different authentication mechanism from a new manager you may've never heard of before, especially if you find out about it because your automated scripts break after the upgrade.
@Dorthu had a good IRL point about this. While Debian may have the means to create a linode-cli alias package that is fulfilled by either linode-cli-old or linode-cli-new, other package management systems may not. Discovering these limitations and best experiences is time-consuming.
I think @nsfyn55's example of user maintained repositories is a fair compromise.
https://github.com/felicianotech/linode-cli-snap
The community side of this says, seek out members of these different distros/package managers and support them for maintenance.
I disagree with following Python's principles here because it's irrelevant of Python. There's people copying and pasting WordPress install scripts who won't know much about or care about Python.
The Linode CLI is a CLI, not a Python SDK or something like that.
The snap linked above supports many Linux distros, Brew is crucial for macOS users. My opinion from personal experience and what we're seeing with the new CircleCI CLI we've release is support a few minimum package managers, at least the main ones per OS, and then support community members if they choose to package it themselves.
Automating the release process is key. When you do that, supporting multiple package managers is little different than supporting one. We've even automated our brew deployments which traditionally would have to be a manual PR to their formula repo.
I don't think it's "wrong" to just support pip, just that when making great software I'd want to make it as easy for people to get it as possible. It's the same philosophy as to why Linode offers more than just Ubuntu and CentOS distros. Barely anyone uses the others, but diversity is beneficial for users. Just a friendly outsider's opinion.
Python principles are life, and should be used in all aspects of said life. :)
On a more serious note, I like using brew because I dev on a Mac, but I am happy to use whatever mechanism is made available to me. I am grateful to Linode for providing a CLI tool in the first place. If pip is the way, then that is what I will use. If I feel strongly that there should be a brew install, I can always make one, and share it.
Thanks for the feedback! After some (a lot) of internal discussion, we're looking into updating the existing linode-cli packages to this version of the CLI in the least disruptive way possible. I'll keep this ticket updated.
Thank you everyone participated in the issue discussion!
After some internal discussion, we don't have a plan to publish linode-cli on the APT repository. You can try to install the new linode-cli from PyPI if you would like to try it out or update from the older version.
