I'm not familiar with the mason registry but I suppose it's relevant to resolve the dependencies or something. And there's no need to update the registry if my package doesn't require any dependencies.
I find it annoying to update the mason registry every time I run some commands when developing mason packages that don't rely on any other packages. I either append --no-update
every time or wait for the update (which is slow in my case). It will be really helpful for me to let mason don't update the registry when there's no need.
I think it would be reasonable to skip the git pull
step of masonUpdate()
call when there are no dependencies generated in the lock file.
@Spartee @krishnadey30 @ankingcodes - what do you all think?
@Rapiz1 - To improve your experience in the meantime, I'd suggest setting export MASON_OFFLINE=true
so that the default behavior is --no-update
.
wait for the update (which is slow in my case).
@Rapiz1 I believe registry is updated only when an user runs mason update
or mason build
. It does a git pull
on the mason-registry if its not updated or clones the mason-registry if it doesn't exist. Also, it generates the lock file from the manifest(TOML) file. So, if you don't have any dependencies and you already have an updated registry (assuming you ran mason build
), I believe updating the registry should be in a flash. I'd also appreciate it if you could give some specific examples or maybe your package link in the issue description so that we could reproduce the behavior(slow update of registry).
@ben-albrecht - If in any case(which I'm not aware of), updating registry takes up a significantly large amount of time, we can definitely support this feature.
I believe updating the registry should be in a flash.
This is true when someone has a good Internet connection to GitHub. Sadly, this is not true for people who may suffer a delay connecting to GitHub through a VPN or something.
Simply running git pull
without file change takes 2 seconds on my machine. It's not about the size of data transmitted. It's about the delay.
Let alone that there are some regions on the earth where the outbound network traffic is deliberately jammed.
Most helpful comment
This is true when someone has a good Internet connection to GitHub. Sadly, this is not true for people who may suffer a delay connecting to GitHub through a VPN or something.
Simply running
git pull
without file change takes 2 seconds on my machine. It's not about the size of data transmitted. It's about the delay.Let alone that there are some regions on the earth where the outbound network traffic is deliberately jammed.