Add stack cp, clarify stack install

[snoyberg]

This was spawned by a mailing list discussion. I'm going to summarize what I think is the conclusion of that discussion:

• stack install is a misnomer, since this is just about copying an executable to a new directory
• As such, we should ideally rename the command to stack cp or similar
• However, many users will expect a stack install command to exist
• So: we'll add a stack cp command with the exact behavior of stack install today, and modify stack install to (1) give a message "you probably meant stack cp" (possibly with a link to this very issue?) and then perform a stack cp

If we go this route, I imagine we should do something quite similar for stack uninstall, but that's really a separate discussion.

[DanBurton]

I think "stack cp" is a weird name for this.

What about the use of stack install to fetch library dependencies? (stack
install text) Or is there a different command for that?

On Sunday, July 12, 2015, Michael Snoyman notifications@github.com wrote:

This was spawned by a mailing list discussion
https://groups.google.com/d/msgid/haskell-stack/59ba0d97-3b87-43db-bed2-62313316db30%40googlegroups.com?utm_medium=email&utm_source=footer.
I'm going to summarize what I think is the conclusion of that discussion:

• stack install is a misnomer, since this is just about copying an
  executable to a new directory
• As such, we should ideally rename the command to stack cp or similar
• However, many users will expect a stack install command to exist
• So: we'll add a stack cp command with the exact behavior of stack
  install today, and modify stack install to (1) give a message "you
  probably meant stack cp" (possibly with a link to this very issue?)
  and then perform a stack cp

If we go this route, I imagine we should do something quite similar for stack
uninstall, but that's really a separate discussion.

—
Reply to this email directly or view it on GitHub
#569.

-- Dan Burton

[drwebb]

There is some similarity to what stack does and the Unix install command which is basically a cp with a umask and possibility to create directories.

[snoyberg]

@DanBurton Every stack command fetches library dependencies, including build. There's nothing install-unique about that. (That's exactly where cabal terminology gets things wrong and confuses everyone.)

@drwebb Be that as it may, many people have assumptions about what "install" means that go beyond what the Unix install command entails, and we need to deal with those assumptions. Answering "technically, your assumptions are wrong because there's prior art to the contrary" won't help us very much ;)

[drwebb]

It's true, we must go by what most users will have in mind when they think of "install", at least this proposal is great because anyone can use the alias. Alas, being correct is not always right </strokes beard>

[radix]

Agreed that cp sounds a bit weird, given that it sounds so general, when it is specifically about copying executables. "cp-exe"? "install-exe"? "cp-bins"? Anyway, I think cp is at least better than install given that install can be so misleading. Just some more suggestions.

[rubenmoor]

make install often also only copies some binaries. If there's no other,
more pertinent functionality that deserves this name, stack install for
the cp thing seems just fine to me.

Also, stack init and stack build implicitly concern the project in the
current dir (stack.yaml and .cabal). Therefore, installing any package
dependency (stack install text was the example) possibly could be
(re)named to something entirely different.

Christopher Armstrong notifications@github.com schrieb am So.,
12.07.2015, 20:02:

Agreed that cp sounds a bit weird, given that it sounds so general, when
it is specifically about copying executables. "cp-exe"? "install-exe"?
Anyway, I think cp is at least better than install given that install can
be so misleading. Just some more suggestions.

—
Reply to this email directly or view it on GitHub
#569 (comment)
.

[drwebb]

Just a new idea after some brainstorming, but I like this one the best out of all the options presented so far. What about referencing the fact that current install has as its purpose to expose the package out of the local .stack-work directory and into the general file system. Just call it stack expose.

[gregwebs]

I like the suggestions from @radix.

However, what makes sense when I want an exe instead of al library, such as hoogle? cp isn't right because I want to fetch it and build it into a binary first, and only then can I cp it into the PATH.

[snoyberg]

Just to confirm: we're all in agreement that:

• We want users to understand that "install" doesn't mean "a package manager installing and managing stuff"
• We're bikeshedding over what that command name should be

If that's the case and we don't have any deep disagreements, let's just make a decision and stick with it. cabal already supports the copy command, so there's that. I don't really care that much about what we call this thing, I'd rather we just call it something and move on.

[mboes]

However, what makes sense when I want an exe instead of al library, such
as hoogle? cp isn't right because I want to fetch it and build it into a
binary first, and only then can I cp it into the PATH.

I'd like to understand the objection a bit better: are you saying that if I
don't have hoogle built yet then cp does more than just cp? How would that
be any different than stack test fetching and building before running
tests? Or stack build fetching before building? The existing naming
convention in stack is that commands are named after the final action they
take. And that unlike cabal-install, but just like make, stack nearly never
refuses to perform that action just because there are prereq actions to be
done first: it transparently performs them for you. DWIM if you like.

In my mind, the nice thing about "cp" and "rm" is that they exactly mirror
the eponymous Unix commands, hence making very clear what guarantees they
provide, i.e. none. And states precisely what they do: they literally are
thin wrappers around copyFile and removeFile that fill in the source and
target for you as a convenience. We could have stack cp --data-files or
whatnot in the future if it turns out to make sense to copy more than just
the executables (eek, package manager territory...). I prefer a flag to a
generically named command here in order to keep the number of top-level
commands small (keeps the cognitive overhead for newbies low).

If all you want to do is make sure you have hoogle somewhere on your
system, i.e. a third-party executable that presumably you're not hacking
on, then you're probably better off apt-get installing that. i.e. using a

package manager.

Mathieu Boespflug Director of Math and Science Software
_FP *_Complete Corp. *

mobile +33 (0) 7 81 47 02 03 <%2B1%20%28858%29%20523%208778> (Central
European timezone)

[gregwebs]

The existing naming convention in stack is that commands are named after the final action they take.

That makes sense. However, cp felt different in this case. I believe it is because when I say stack build my goal is to literally build something. After building a project, if I want to expose the executable in the path, than cp reflects my mindset well enough. However, if I want the hoogle executable to exist in my PATH, than cp is an implementation detail of the fact that stack is performing a build from source rather than downloading an exe.

So my mindset is more of "put this exe in my PATH", which is probably better reflected by the "expose" suggestion. Naming it "exe" for "executable" would be good if "exec" were not already a command. "bin" is an alternative.

@snoyberg sorry for continuing the bikeshed :) I will be fine with whatever is chosen, I just wanted to make sure all the use cases are being thought of first.

[gregwebs]

one more example: Docker uses ADD to indicate that something might be copied from a file or downloaded from a url. I don't think add works in our case though because we are not adding a file to an image.

[snoyberg]

Alright, here's my opinionated approach to both this and the stack uninstall command: #602. I of course decided to bikeshed even further, and rename stack cp to stack copy (for naming consistency with cabal, and to avoid a mismatch in the behavior of stack cp and the Unix cp command).

I'll hold off on merging until everyone has a chance to complain, since the Haskell community loves bikeshedding names so much :-P

[gregwebs]

I am ok with whatever is chosen since I cannot come up with a clearly better alternative.

[radix]

@snoyberg 👍

[drwebb]

I'm will be happy with what is chosen as well. We spend a lot of time naming things! This is a big one though that I personally will actually type more than anything, cp has the real advantage of being about as quick to type as anything. On the otherhand, it sounds like one of the most used unix commands but has a much more limited function. I think a common use with it will be the new --local-bin-path option that comes in the next release, stack expose --local-bin-path ~/bin sounds like it's actually doing something, like it's unveiling the package from .stack-work or stack-root directory into some local to the user location. I did a quick google on the use of expose as a command, and not much turned up, but at least I could quote some people using the term in order to mean installing something on a PATH. Okay, bikeshedding over, I'll go with whatever @snoyberg choses.

[gregwebs]

The point I brought up is that if a new user want to use hoogle, they probably won't think to run the command stack copy hoogle. stack install hoogle will make a lot more sense coming from using different package managers.

Another possible downside is that I can run stack copy exe1 when I actually meant to type project2. The result of this is that stack will go looking for the package on hackage and could install a package with the incorrect name.

There is also an edge case here: if my package is already on hackage, and I want to download and install the hackage version to my path, what is the behavior? Investigating this led me to open #606. It seems that stack will not look for a remote version of a local package.

To me it makes sense to have 2 separate commands: stack fetch, and stack copy.

stack copy: build -> copy to bin
stack fetch: download -> stack copy

But I am happy to leave this as a future enhancement. As long as the install command is still available in a deprecated form, new users may be able to figure out to use stack copy.

[snoyberg]

OK, after a little more pressure, here's my final suggestion: we use stack build --copy-bins when we want to be explicit about this. To quote the commit:

Motivation:

• stack copy annoyed people
• copy-bins is much more explicit
• --copy-bins is composable: can be used with stack build, stack test,
  etc
• One less top level command taken from the available namespace

I'll give this another day before merging to master... but then I hope
we can move on to real stuff

[gregwebs]

This sounds good to me. To clarify:

• stack test --copy-bins means only copy the binaries if the tests pass?
• To use hoogle I run stack build --copy-bins hoogle ?

[snoyberg]

Yes, exactly.

[istathar]

Damn, I hate being late to the party. Sorry, but ``stack build --copy-binsis awful. I'd recommendstack build --install`, except that that obviously shortens to `stack install`. Can we lobby to revert this?

AfC

[istathar]

Furthermore, if there are things other than binaries that do need installing, then stack install is the right place to do it. You had it brilliantly figured out: install to ~/.local/bin, permitting self-upgrading. If other things need to be installed, then they can go to ~/.local/share/* etc just as they're supposed to.

The only thing you're missing, perhaps, is the notion of either configure --prefix=/usr/or/whatever and/or DESTDIR=/build/target make install — those are the things that allow a package manager to pick up the result and plonk it whereever you're going. Your until two-days ago brilliant defaults were to assume it's a user and that they just want to install it locally so it works. All that's needed is the ability to support other prefixes and temporary install target directories.... to install.

stack install was precisely the correct command.

AfC