Contributing guidelines recommend setting the main branch to upstream remote, but Lazy only supports remotes called origin

[lougreenwood]

Checklist

• I have searched through the AstroNvim docs
• I have searched through the existing issues of AstroNvim
• I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)

0.9.1

Operating system/version

macOS 11.5

Terminal/GUI

iterm

Describe the bug

Given a user which has a local copy of astrocommunity and is using that for their packages & development, and if the user also has a remote for the astrocommunity which is named upstream (as the docs suggest).

When the user attempts a fresh install (clean ~/.cache/nvim ~/.local/share/nvim & ~/.local/state/nvim), the install of all of the plugins will fail because lazy seems to not work with remotes named anything other than origin.

folke/lazy.nvim#602

I hit this issue and struggled to understand why my things were not installing correctly and my setup was broken, after finding the above link I changed my remote to origin, wiped everything and started again and it was successful.

I didn't save the error and I can't find it in my history, but the steps to repro should help.

Steps to Reproduce

• Setup a local copy of astro community with an upstream remote according to the contributing guidelines
• Make sure this local copy has master checked out
• Delete the local nvim state files so that lazy / mason etc must re-install
  • ~/.cache/nvim ~/.local/share/nvim & ~/.local/state/nvim
• Open nvim and see lazy begin to install it's dependencies
• See that there is an error and not all deps are installed (astrocommunity) won't be cloned or something like this.

Expected behavior

I guess the contributing guidelines need to be changed to call the remote for the main branch origin, either that or we need to lobby for folke/lazy.nvim#602 to be implemented!

Screenshots

No response

Additional Context

No response

[mehalter]

This doesn't really make any sense. When you use dev = true or specify a directory where the plugin is then Lazy does not manage it at all with git.

The linked bug report to lazy.nvim is already closed since it was implemented to support when git is configured with a different default remote. That was just a bug completely separate from plugins being in dev mode.

Not sure what sort of error you are getting. I have a local AstroCommunity clone with ~50 remotes that I use regularly. It's in ~/projects/astrocommunity and I have this as a test user/init.lua file:

return {
  plugins = {
    { "AstroNvim/astrocommunity", dev = true },
  },
}

I can delete all of the cache/data/state folders and do a reinstall and there is no error. It doesn't clone AstroCommunity since it is in development mode and it's up to me to manage that. I can check out any branch on any remote and it just uses it.

[lougreenwood]

I guess I missed adding the detail, but I'm not using dev - true. Instead I have it setup like this where I specify the path for the AC local repo.

return {
  "AstroNvim/astrocommunity",
  dir = "~/Code/astrocommunity",
 
  -- defining the AC packages to use goes here
}

It's late for me now, but I'll try to reproduce again tomorrow and share the error (and maybe a video etc) 👍

[mehalter]

Yeah that is the same. When you specify the directory then lazy does not handle interacting with that folder for git operations. So if you want to use whatever remote you want then you just check out that remote. Lazy will not pull updates for you or anything

[lougreenwood]

Also, here's a screenshot showing that astrocommunity is checked out by lazy into ~/.local/share/nvim/lazy and it's using the remote i specified and is using the latest master (not 5.0.0).

[lougreenwood]

And here's my .git/config for my local copy of astrocommunity.

Notice that I have 2 remotes, dev & origin and the master branch is using the origin remote.

However the contributing recommends adding an upstream remote which references https://github.com/AstroNvim/astrocommunity (and by default the forked repo would be origin).

[mehalter]

Yeah there should be no folder in your lazy directory, if there is it won't be used

[mehalter]

It will just be using your local directory that you specified. I just tested with this:

return {
  plugins = {
    { "AstroNvim/astrocommunity", dir = "~/projects/astrocommunity" },
  },
}

the remotes in that directory are irrelevant to lazy

[mehalter]

Here is an example of what I'm saying: if I do ls in my ~/.config/nvim/lazy directory you will see that there is no AstroCommunity clone there since lazy isn't handling it:

Instead it is showing in lazy that it is at the local directory:

I'm guessing you just got a bit confused with how lazy manages repos and what folder it's using. But yeah the folder in ~/.local/share/nvim/lazy and your local development folder are completely separate.

[mehalter]

for you to switch branches you just have to do that yourself. If you want to pull changes, etc. Lazy will not do any git operations on that directory what so ever. So doing like :Lazy update will not affect any local plugins that use dir or dev

[lougreenwood]

I got nerd sniped and tried to reproduce 😓, but I wasn't successful this evening... but I'm tired and I have another idea for tomorrow morning.

But I can say with certainty that Lazy is checking out astrocommunity, I just deleted all of ~/.local/share/nvim and re-opened nvim to force lazy to re-install everything and astrocommunity was checked out into ~/.local/share/nvim.

I'm also going to check my browser history to see if I can find the error, because after setting the remote to upstream and then wiping my local install I definitely got an error and IIRC, that error mentioned upstreams. Then when I googled that error I found the issue in the Lazy repo which I linked in my earlier comment.

[lougreenwood]

A question to help me for tomorrow. I see that astrocommunity is versioned. When using ac as a usual end user, without dev or setting the dir path, would the user get the repo tagged at release 5.0.0 or the current & up-to-date main?

[mehalter]

If it is the case where it is still cloning it. Then you should look into that because it strictly shouldn't be. If it is that indicates it will just not be using your local directory. I would recommend checking lazy to see if it's marked as using your local directory. If not, then you have incorrectly set up development mode for it (either using dev or dir).

Also that is entirely up to the user. If they tell it to track stable versions then it will, if not then it won't. Lazy by default doesn't only track versions/tagged releases. It will just pull the latest.