[Issue/Feature]: Improve support for upstream branches

[jsyjr]

Feature Description

Recently I was asked to try out an experimental branch that a package developer had created. I updated my use-package :ensure clause to include a :branch "branch-name" spec and ran elpaca-pull-all. To my mild surprise, that elpaca-pull-all command completed without evidence of any issue.

After poking around in elpaca's local repo for the package, I determined that the repo had no knowledge of the branch, neither upstream nor locally. Manually creating, configuring, and checking out the new branch within elpaca's repo solved the problem.

At a minimum, should not the lack of availability of a :branch within elpaca's local repo result in some form of diagnosis?

More ideally, the lack of availability of a branch could trigger probing the upstream repo for a branch of the same name. On success, elpaca could preform appropriate reconfiguration of the local repo.

Confirmation

• The feature I'm proposing does not already exist in Elpaca

[progfolio]

Feature Description

Recently I was asked to try out an experimental branch that a package developer
had created.
I updated my use-package :ensure clause to include a :branch "branch-name" spec and ran elpaca-pull-all.

elpaca-test is the appropriate tool for that.
It will allow you to experiment in a clean environment without altering your configuration.
It's better for short-term development as in your example. e.g.

(elpaca-test
  :interactive t
  :init
  (elpaca (example :branch "experimental-branch")))

Manually creating, configuring, and checking out the new branch within [the package's] repo
solved the problem.

That is also by design. The package manager sets the initial state of the repository, but it isn't checked on every startup for performance reasons and development flexibility.

At a minimum, should not the lack of availability of a :branch within elpaca's
local repo result in some form of diagnosis?

It will during an initial install of the package.

More ideally, the lack of availability of a branch could trigger probing the
upstream repo for a branch of the same name. On success, elpaca could preform
appropriate reconfiguration of the local repo.

That could be added via custom build steps, but it's not something I plan on adding by default.

[jsyjr]

I understand all that wrote. And now that you remind me, I do remember reading about elpaca-test, but, having never used it, it did not spring to mind. Thanks for the suggestion.

That is also by design. The package manager sets the initial state of the repository, but it isn't checked on every startup for performance reasons and development flexibility.

My issue is not with omitting checking on startup but rather on pull.

[rileyrg]

Just to add here that I was wondering the same thing : I changed the branch name in my mu4e and expected a fetch/rebuild but it didn't. I can understand you dont want to check a remote git repo every start up, but assuming elpaca keeps some metadata about installations, caching the build branch and seeing it has changed wouldnt be too much of an overhead would it? Could be naive, but its behaviour did seem counter to having a branch attribute if its ignored on subsequent starts. The only way I got this to update to a different branch was to delete build and repo for mu and restart.

As a side note : I got my init converted to elpaca, and it's great - very thought-provoking and it inspired a big clean-up ;) It's quite thrilling to see elpaca cloning multiple packages in parallel when recreating .emacs.d/elpaca ;))

[progfolio]

Could be naive, but its behaviour did seem counter to having a branch attribute if its ignored on subsequent starts.

Elpaca is designed to accomodate elisp package development, too.
From a developer's standpoint, I don't want the package manager switching branches on me whenever I restart Emacs because what I'm working on doesn't align with what's declared in my init file.

The only way I got this to update to a different branch was to delete build and repo for mu and restart.

You can also use version control tools to do this (e.g. magit, emacs's built-in vc package, etc). I plan on adding ways to force the repo state to match the declaration via a command in the future, but there are still open design considerations.

As a side note : I got my init converted to elpaca, and it's great - very thought-provoking and it inspired a big clean-up ;) It's quite thrilling to see elpaca cloning multiple packages in parallel when recreating .emacs.d/elpaca ;))

I'm glad you're finding it useful. Thank you!