packer.nvim
packer.nvim copied to clipboard
wbthomason
Set max_jobs default to 10.
just as with mac setting max jobs default does not make sense if you need a hack to make it work then put it in your cfg or adjust your local dev env / nvim config to make it work
for me on neither windows, mac, linux requires max_jobs to make my cfg work
this is a no fix imo
just as with mac setting max jobs default does not make sense if you need a
hackto make it work then put it in your cfg or adjust your local dev env / nvim config to make it work for me on neither windows, mac, linux requires max_jobs to make my cfg work this is a no fix imo
I've had two Mac's in the last year, and it seems like a consistent issue. I feel like it should be a default until the actual fix is done so no user has to search for an arbitrary issue in Packer's github in order to find the workaround which isn't super clear as to how to set it up.
this is not a issue on packers end but a issue on limiting the amount of changed files at once in the macOS FS
ulimit -n 4096 set this in your shell setup and packer should be working just fine
for mac only of course
@wilkinson4: Sorry for taking so long to get to this! I'm a little leery of setting this - as @danielnehrig notes, the default works well and improves operation speed on non-macOS systems. Is there maybe a way we could gate this to only apply to macOS, perhaps by using jit.os (https://luajit.org/ext_jit.html) ? The only thing is I'm not sure how jit.os behaves on non-OSX macOS versions.
@wbthomason just FYI since I think I raised the initial issue for this behaviour on macOS and I believe there have now been several duplicates most of the issues relating to packer hanging on macOS are as I pointed out due to the number of jobs a terminal can spawn by default in macOS being quite low so if a person has multiple terminal or apps open they hit that limit really quick.
Tbh this is something that macOS should allow to be fixed much more easily, but I've recently after a lot of digging found a solution https://github.com/akinsho/dotfiles/blob/7e6f90b79a4b64589616daac50674b8fe49d5d6a/neorg/macos.norg which I've documented in my dotfiles. I think the way to handle this is with a very clear note for macOS users to implement a similar solution.
I've previously mentioned ulimit as a solution, but this solution doesn't work on more recent versions of macOS
I think dropping it by default will degrade the experience on macOS so even if a user doesn't want to use that solution then it should be something documented very clearly rather than maybe forced on the user since 10 is very low so slow and the higher you go the more likely they will run into the issue anyway
