search

fnogatz / swivm

SWI-Prolog Version Manager - Bash script to manage multiple active SWI-Prolog versions
MIT License
41 stars 8 forks source link

head alias #12

Open Anniepoo opened 5 years ago

Anniepoo commented 5 years ago

Enhancement request

swivm install head - installs latest master from github swivm use head - uses it

Handy for picking up new changes. If you're on HEAD you have to manually install, then turn off swivm

fnogatz commented 5 years ago

First of all, we need to add support for git-based installations. I've been thinking about the best interface to provide this.

The current installation command is swivm install 8.1.9. I would like to extend this to support git commit hashes, e.g.:

swivm install df7c7a
swivm install df7c7a26aadb0dd8d412a8f0faa10c9cb6481ef3

Given this interface, we could also add the head alias, similar to the already available swivm install stable and swivm install devel. swivm install head then installs from the latest git commit to the master branch. Given that this is df7c7a, this would have the same effect as calling swivm install df7c7a && swivm alias head df7c7a. Note that updating to the latest changes would require calling swivm install head again. Note that with this architecture, the installation is actually not updated using git fetch but downloaded a second time instead by using git clone.

What's your opinion on this, @Anniepoo? Maybe @JanWielemaker might also comment on this :)

I am also thinking about how to distinguish the then three different installation methods. As of now, we download tarballs from the SWI-Prolog website, or if not available from GitHub releases. With support for git, we add the third method to use git instead of downloading the tarball. After all, we might allow users to choose might method to use when calling swivm install 8.1.9. But how?

swivm install stable --git
swivm install stable --from-git
SWIVM_SOURCE=git swivm install stable
...?
JanWielemaker commented 5 years ago

An option and an environment variable providing the default seem ok to me. Frequent users will simply set the environment variable. Note that git clone takes the flag --depth to make a shallow copy of the history. I think that will make the clone hardly slower and more costly than the tar ball. Never really used it though.

Anniepoo commented 4 years ago

I don't see anything wrong with use head using the most recent head you've installed. While obviously this means you might not truly be on head, 90% of use case for this is simply to pick up a needed recent change.