Changing VCSH to require an Install?

[arndtc]

VCSH is a script that I've been using for years to maintain my $HOME on many systems, most of which I don't have access to install packages. So I would just clone the repo master/main branch and use the script form there.

So I just did my regular update and all the sudden it broke my workflow. I've been reading through the latest docs is seems that I have to compile/install the script, or I can down load a pre-compiled versions. I find it a bit strange that I need to do these extra steps. I can't find anything that really shows the advantages of these changes. There was some mention of compatibility issues, but is this really a bit issue? I'm not seeing any problems on the various machines I've been using.

Can someone explain why there was such a big change and what advantages this brings?
I'd like to understand the implications and how I need to update my work flow, or if I should just back up and freeze on an older commit from the repo.

For the short term, I've switched to using the release branch. Probably should have been using that all along, but there were just so many branches, that I didn't know which to use, so just defaulted to the main branch.

[alerque]

If you want the "just a simple script" version, you can download it from the releases page attached to any current release (currently only v2.0.0-beta.1). The default filename as attached to the release is vcsh-standalone.sh but as documented in doc/INSTALL.md#standalone-script you can download and save it under the name vcsh if you like. Note that calling this a "pre-compiled" version is a bin of a misnomer because it's a POSIX shell script not a compiled binary, but it is configured. In the case of the standalone script it is configured to use your $PATHs for locating everything at runtime.

Please don't use the release branch as that mechanism is a deprecated work-around to handle build time dependencies like the Ruby scripts used to build the man pages. That's not how future releases will handle that problem, please don't use it. Again see the INSTALL docs for how to use either the system configure/install bundle or the standalone script including URLs for fetching it.

There has been quite a lot of ink spilled talking about the issues distro packager had before that have been smoothed over now. I won't go into it all here because if you want a user-space script version, the standalone build is what you want. If you want to install it to your system with matching man pages, shell completion functions, etc. then the advantages of a proper configure and install step will be apparent soon enough.

[alerque]

For some of the spilled ink that goes into detail about what situations were improved and what use cases there were for different builds, see standalone scripts issues discussed in #202 and addressed by #299, early attempts at fixing build issues in PRs #100, 167, and then eventually #288 which introduced the current configure system.

Does the info above about where to download the vcsh-standalone.sh script version answer your question? Is there anything about your use case not covered by that? If so we'd be happy to hear about what need you have that isn't being covered well.

[arndtc]

@alerque Thanks for the links to the previous discussion. #299 was the one I was looking for. It basically covered the same issue I had, where I have a bootstrap that I use for all my setups. With that said, I was also using the main branch to keep my setups up to date as well. I realize that using the main branch is probably not the best choice, but there were so many different branches and tags I couldn't figure out the versioning scheme how to stay automatically synced with the latest version. I found that using main worked, I just stuck with it as it gave the the advantage of making sure that I always had the latest version on all my machines. I think that the pre-configured versions should work for me, but I'll have to come up with an new solution for automating the update to the latest version.

I use vcsh in conjunction with myrepos (mr), so I should be able to come up with a solution.

[alerque]

Thanks for reporting.

The standalone script instructions include URLs that will help you automate downloading the latest version. To that I would just add:

• The latest keyword won't work yet because the only release available is a beta marked as a per-release. It will go live when the release is official. We would love have you actually use the standalone build on the beta release and report if there are issues.
• Even when it does go live, we still strongly encourage you using tagged versions known to work with the rest of your script and update deliberately while checking the changelogs.
• If you do automate version bumps, consider not jumping past major version numbers. We don't have any breaking changes in mind, but any potential v3 would probably be because you shouldn't just blindly update and expect it to run the same way. Note the v2 release is appropriate partly to fix the how the release cycle happens and how people download the script. There are also lots of other small fixes and improvements, but the deployment change is the big one.

I'm going to close this because I think we have your use case covered already. If something comes up that doesn't work or isn't as easy as it could be please do report back here or open a new issue.

Also I'd be curious to know why you don't use your system's package manager to update VCSH.