Option to install version of tool globally about mint HOT 13 CLOSED

We're running into the difficulty of where to install it on in this PR for marathon too: JohnSundell/Marathon#127

from mint.

Maybe Mint should install a version to /usr/local/bin everytime you run mint install or mint update. It would be copied to the versioned directory in Mint but also globally.

The downside of this is that you might overwrite a tool that requires access to resources and was installed with valid access to those resources using something like homebrew.

from mint.

I'm wondering if for danger-swift, a global install is probably my best option option.

I need to read from STDIN - which could work if mint install/ mint run passed through any existing I/O and passed the results back through to the host process. When I looked at the run implementation, it'd basically have to be re-written to support that though

from mint.

Yeah, I really want to get realtime reading/writing of of STDIN in Mint, which is also mentioned in #3.

In terms of installing globally there are a few options:

• use new command (name?)
• use new flag for install (something like --global)
• always install globally on install as well as locally (could be disabled with a flag as well I guess)

Which one do you prefer?

from mint.

IMO, it depends on where you want to go with the project, right now it's very much like npx. Allowing a global install would make it a lot more like npm/rubygems/brew. Adding global support does however act more like a cli tools package manager though. So personally, I'd prefer the support.

I think adding the param --global makes the most sense. Ideally you encourage most use-cases to use mint run xxx. I think #3 might make it possible for danger-swift to not need it either.

from mint.

In terms of installing globally there are a few options: [...] Which one do you prefer?

install seems to intuitively imply the ability to use the tool directly from the shell, so my preference would be...

• always install globally on install as well as locally (could be disabled with a flag as well I guess)

The most user‐friendly interface would be simply:

$ mint install Someone/Tool
...

$ tool version
1.0.0

...and...

$ mint update tool
...

There is definitely room for sensitivity though, such as when versions are specified:

$ mint install Someone/Tool 2.0.0
...

$ mint install Someone/Tool 1.0.0
# ...uh? Should it be overwritten? (Probably not, at least by default.)
...

from mint.

I think throwing the build result naïvely into usr/bin/local would be unwise.

• The system and other package managers could be changing things behind Mint’s back and vice‐versa.
• Two packages may require the same dependency at different versions. They could not be installed at the same time. (Static linking would avoid this, but it means several executables in the same package no longer share dependencies, needlessly increasing size. Static linking is not swift’s default, and it is currently unstable according to the release notes.)

I would recommend Mint:

• make its own directory for global installs,
• place symlinks into the directory pointing at the globally selected version of each executable (but not at libraries),
• permanently register the directory in PATH for a reasonable selection of shells.

from mint.

I think that's a good approach @SDGGiesbrecht. What do you think @orta?
Only downside is a slightly more intrusive install as we add a new PATH.

Why doesn't homebrew do this? They just place symlinks into /usr/local/bin

from mint.

@yonaskolb

They just place symlinks into /usr/local/bin

...and do all sorts of additional safety checks and permissions adjustments—and still lost control of the directory upon updating to El Capitan and had to start over...

It can be done, it is just more complicated than it looks. It is up to you.

Speaking of permissions: Have you thought about what happens on multi‐user machines? Currently the executables are placed outside of any user. Maybe the dependencies you are using for file operations already handle permissions for you, but it would be worth verifying. (If not, the simplest fix might be to install on a per‐user basis into, say, ~/.mint).

from mint.

No I think having a seperate directory and a new PATH is better, I was just wondering why Homebrew decided against such a move.

You make a good point about different users. I had assumed that the files had global permissions but that might not be true.

from mint.

Stdin support moved to here #37

from mint.

I'd like to get this added. Is there a standard way of adding a new $PATH to most machines? Ideally it would be something that happens in make install. If it requires sudo that can make people wary

from mint.

Is there a standard way of adding a new $PATH to most machines?

Unfortunately not. There is no way to be 100% sure you have covered all shells in all log‐in situations. You just support what you know about and add more when someone asks about it.

This is what I use right now, which was originally based on the behaviour of RVM and the Swift Version Manager. It targets several configurations of bash as well as zsh and fish on both macOS and Linux. Lines 86–88 and 93 add entries to the respective log‐on files; line 89 exports it for the current session too (otherwise the user must restart the terminal before it takes effect). Everything is on a per‐user basis, so sudo is unnecessary and the system is not vulnerable to mistakes.

If you want to provide more fine‐grained control, you could let users configure which shells they care about and skip the others, or set Mint installations to be either overrides (prepended to $PATH) or fallbacks (appended to $PATH).

Ideally it would be something that happens in make install.

It depends what you want. If you implement it directly in the mint executable it would be self‐repairing, testable, and present during development experiments. In addition, one could then fully resolve and install the latest stable version of Mint with nothing more than:

working_directory="/tmp/Mint"
git clone https://github.com/yonaskolb/Mint "${working_directory}"
cd "${working_directory}"
swift run mint install yonaskolb/Mint

No need for the Homebrew formula anymore.

from mint.