Add unpack --update-stack-yml

[alexanderkjeldaas]

This is a common use case.

[mgsloan]

What's the goal? To generate a stack.yaml? IMHO, this isn't much more convenient than cd-ing into the dir and doing stack init.

[rvion]

from what I understand, @alexanderkjeldaas would like unpack to automatically update the packages list in stack.yaml

packages:
  [...]
   - new_unpacked_pj

Even if I agree this is a quite common use case, I'm rather -1 on this specific proposal, because I think #115 is a better approach to solve all those common stack management requests

[alexanderkjeldaas]

The #115 proposal is not discoverable.

Here's the use case based on my "real needs" today:

Some User wants to write a servant-client API. For some reason, the tests fail on a real server.
"How could that be?", ponders Some User.
Some Users thinks for himself: "I really need to know what servant-client sends to the server, but I can't use wireshark because the API is https only!".
"I will have to reimplement my OS".

Some User then looked for some stack command to download servant-client. stack revealed the stack unpack command which would download the package into a local directory.

Some User then asked on #haskell what the next steps would be.

Some friendly soul informed Some User that the correct next step would be to update the stack.yml file like so:

packages:
  - servant-client-0.4.4.5

All was bliss, but if there was a discoverable next step to stack unpack then no interaction with #haskell would be needed. This discoverable next step would be documented in stack unpack --help, and if documented there, why not have an option to do the right thing?

[mgsloan]

Ah, sorry, I misunderstood the suggestion since your original issue is so light on details.

I've also wanted something similar-ish in the past, but not quite a direct unpack. I think this may be a bit too git specific to go directly into stack, but:

• Unpack the correct version of the package to a temporary directory
• Clone the git repo specified in the cabal file
• Find the git version that matches the files. There are a few ways this could be cleverer than linear search. E.g. using package upload dates, looking for version numbers in git tags, etc.
• Add a submodule with the correct SHA
• Remove the package from extra-deps, if it is one
• Add it to the packages list

The reason for this is that usually I wouldn't want to check in the code of some other package. If you want to modify the code of some dependency, and actually track this change in version control, then it makes more sense to use a submodule or subtree.

So, I think the reason I've never felt the need for stack unpack --update-stack-yaml is that usually if I want to do something like this, I want the above workflow. I suppose such a flag could be handy for experiments with modifying dependencies, which don't get checked in.

Particularly since this is a step towards something I'd really like to have (stack unpack --submodule), I wouldn't mind adding something like --update-stack-yaml. The behavior of this flag should be the last two steps from above:

• Remove the package from extra-deps, if it is one
• Add it to the packages list

How about adding stack config add package NAME, which does the above steps? Then, --update-project (I think I prefer this to --update-stack-yaml) would just call into the config modification code.

[harendra-kumar]

I would support having a command like stack config add package NAME.

If we are adding a config subcommand then stack init becomes stack config init which is in fact an auto version of stack config add. stack init discovers all packages under a dir or dir tree and adds them to the config file. stack config add and stack config delete could be the fine grained building blocks for manipulating the config file via command line.

The current stack solver command then becomes stack config solver or maybe we can call the non-modifying and modifying versions of this command as stack config verify (or check) and stack config fix (or repair or solve). The verify/repair commands can also check for any deleted or unreachable packages and remove them from the config. The solver should run automatically on any modification involving dependency changes including add and delete.

[harendra-kumar]

Adding comments from #1978 in order to close that one and keep this one.

---

@angerman wrote:

Fair enough. Maybe I'm using it wrong then. I usually use unpack, if I need to make local modifications to a package to suite my needs (and later turn those into a proper PR for the package).
Hence the workflow is stack unpack XYZ, edit the stack.yaml and extend the packages: section. Thus, if stack could do that for me automatically, that would be great. Am I making any sense?

---

@harendra-kumar wrote:

Yeah, it definitely makes sense. We need something for "I want to pull a package from an index and add it as a local dependency package to my project". I think I thought about this before. I am imagining a stack add sort of command which:

• adds a new package to an existing project
• solves the dependencies for the whole project with the new package
• adds any extra dependencies if needed just like stack init/solver
• keeps all other stack.yaml settings intact

Now we can add a --dep option to this new command which will solve your workflow. I guess we have all the pieces in stack init/solver to do this, just a little bit of glue work is needed.

With that your workflow will be stack unpack X; stack add --dep X. You have the motivation, would you have time for doing that :-)

[snoyberg]

Closing, as we're not going to be adding this to the unpack command.