-
Notifications
You must be signed in to change notification settings - Fork 328
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bug: hererocks build failed because "python: command not found" #1548
Comments
Also, after I've symlinked python3 to python locally, the build failed again. This time because missing
I had to install it on my machine to finally get the plugin built:
|
oh true lua headers can be another issue |
Having the same issue when hitting Update for all plugins |
Sigh, luarocks really is pretty fragile... |
What if I'd just disable automatic luarocks packages completely? |
that just makes it a pain for plugin authors and users ig otherwise this will make plugin authors think twice if they really want to use luarocks (or just be a pain for the ones who need things from there) and also requires users of such plugins to install things just themselves perhaps @mrcjkb and @vhyrro could provide some help here with their experiences from luarocks.nvim and rocks.nvim things |
I think that's a sensible approach. I understand the intention, but I personally feel as a neovim plugin manager, we should not try to install a lua package manager especially when no binary distribution is provided for the various platforms we strive to support. |
The biggest issue right now is plugins that also have a rockspec where they define dependencies to other Neovim plugins. There's currently no way I can resolve these deps to the correct github paths. I have no idea how to do that (without using Like this one https://github.com/mfussenegger/nvim-dap-python/blob/master/nvim-dap-python-scm-1.rockspec |
I'm talking about the fact that plugin authors are responsible for the fact that their plugin needs an additional system dependency
that shouldn't be an issue though if these are on luarocks right? |
Is there a workaround to disable building hererocks for now? I don't need this functionality, but I really need to get Lazy working again. |
ig with the |
Lazy looks for the 'python' command, which doesn't exist on Debian 12. Ref. folke/lazy.nvim#1548
In case this helps: In rocks.nvim, we have a bootstrap script that works quite well on unix and doesn't depend on hererocks. Our bootstrap script doesn't work with non cygwin Windows yet. It'll probably use the It's probably a good idea to silently disable luarocks packages if no luarocks executable is found and it can't be bootstrapped. |
Thanks, this works for me |
I think this is a big improvement Because ig that will work for a lot of users (even more if we'd extend the script to use hererocks as a fallback) which would just lead to less failed installs |
Can't even get luarocks to work with my mingw installation in Widnows.
|
Does anyone know how I can find the rockspec for a rock name? |
When I restart Neovim, luarocks also sometimes won't launch at all. |
The whole luarocks ecosystem is a mess. I'll leave it as is for now, but I'm strongly considering to make luarocks opt-in. |
Plugins should really just use a |
I think the most important thing to be gained from luarocks is installing things which aren't neovim plugins like |
Example for neorg 8.7.1-1 https://luarocks.org/manifests/neorg/neorg-8.7.1-1.rockspec You can find versions in the manifest: |
@mrcjkb that requires the user name of the package to be known as well, but that's something that I don't know. That nvim-dap-python package for example depends on nvim-dap. I would like to be able to ideally resolve nvim-dap to its GitHub repo. If a Neovim plugin only has a simple build step and depends on only neovim plugins, then I can skip luarocks altogether in that case. |
That use case makes sense and this should of course still work. I just want to prevent needing to use luarocks for things like telescope, plenary, nvim-dap and others that don't really need luarocks to work. Ideally luarocks should only be used when needed. |
@folke sorry I posted the wrong URL https://luarocks.org/nvim-dap-scm-1.rockspec works too. The problem is that not all rockspecs have a git source. Some (especially semver releases) might have a zip archive as the source.
I think if luarocks packages aren't first class citizens then luarocks support should definitely be opt-in (and plugins that require it could enable it in a lazy.lua) file. |
Sweet! Thanks! |
Take a look at https://github.com/rockerBOO/awesome-neovim and find me three plugins without It also doesn't really matter, since lazy is capable of installing any luarock url. The issue I'm solving is where some Neovim plugins are listed as a dependency in a luarock, but might also be in your lazy spec somewhere. Currently that would be two different things on your package path. This can potentially lead to issues. Pretty much all of the Neovim plugin rockspecs I looked at, had either no dependencies or only Neovim plugin dependencies. So for those cases, the rockspec should only be used to determine dependencies and let lazy handle the rest. For more advanced plugins like Neorg, |
I didn't realize how messy this was. It is obvious when looking at a plugin that it uses a Lua rock? |
yes it is because of the rockspec |
|
So |
well this will also be the case for the completion plugin I'm currently working on (and perhaps there are also other things as well) |
Just one plugin aff7ee8 |
But again, that doesn't really matter that much. It will work nonetheless |
The new code is live. For neorg, you'll now see all it's depenencies and their depedencies as separate plugins in |
My issue with |
just one thing (would take too much time to go figure that out in the code) not that I had an example where it mattered |
also just for clarification because of the recent changes and discussions about opt-in or opt-out lazy does by default now parse pack-spec, rockspec and lazy.lua is that correct? |
Good point, versions are currently silently ignore. ha.
Yes, correct. With the latest changes, if a user didn't need |
To be fair, the luarocks ecosystem itself isn't a mess. It just isn't intended to be used in a way that doesn't treat lua rocks as first class citizens. To elaborate: luarocks installs rocks into a tree that separates library ( Some Nvim libraries double as plugins and libraries, but don't need to be plugins for the average user. The idea of using luarocks to manage plugins as first class citizens is:
In our [nvim-neorocks org] experience, this works quite well. The main PITAs we still have are;
... which is why I was a bit surprised that this was merged and released so quickly.
There exists no standard for declaring such things, so it wouldn't be very useful for diversity. Footnotes
|
@folke many neovim plugins have |
The biggest issue is tooling as far as I can see.
Lazy does, and also now does it for
As I said before, with lazy v11.0, all of the sudden, some of user's plugins needed luarocks. |
This would require to download all rockspecs, unless there's a repo somewhere that contains them all? |
Ah, I had assumed you were downloading the rockspecs already. I guess you could have a cron job that crawls a subset of https://luarocks.org/manifest-5.1, but that might be overkill for the few plugins that don't have nvim in the name. It would probably be easier to just add the popular ones manually. |
I'm currently using https://luarocks.org/manifest. |
Closing, since op's original issue was also fixed. |
Probably not a bad idea. 5.2..4 rocks won't work with neovim anyway. |
Also the https://github.com/nvim-neotest/neotest - is published to luarocks |
Lazy looks for the 'python' command, which doesn't exist on Debian 12. Ref. folke/lazy.nvim#1548
Did you check docs and existing issues?
Neovim version (nvim -v)
NVIM v0.10.0
Operating system/version
22.04.1-Ubuntu
Describe the bug
After fresh installation, I can see the following error:
It looks like the offending line happens here:
lazy.nvim/lua/lazy/pkg/init.lua
Line 124 in 9005e8e
I think we'll need to check the availability of python before we start, and many people will have
python3
in their path instead ofpython
.Steps To Reproduce
Install neovim with latest version of lazy. Open an empty file, lazy screen will pop up showing the aforementioned error.
Expected Behavior
Nothing should appear.
Repro
No response
The text was updated successfully, but these errors were encountered: