search

gnolang / gno

Gno: An interpreted, stack-based Go virtual machine to build succinct and composable apps + Gno.land: a blockchain for timeless code and fair open-source.
https://gno.land/
Other
895 stars 372 forks source link

GnoDev - Conflicting Package Resolution Between Personal Repo and Examples Folder #2665

Open Molaryy opened 2 months ago

Molaryy commented 2 months ago

Description

I was preparing to create a PR to the examples folder with a project from my personal repository. I copied the contents of my realm and package into examples/gno.land/r in the main repository. In my code, I decided to change a type from int to uint64 because the value will never be below 0 in the package that I copied to the examples folder.

To test the changes, I made the necessary updates in my personal repository and used gnodev to check the results. However, I encountered an issue where gnodev sometimes picked up the old version of the package from the examples folder instead of the updated one from my repository. This led to errors that I had already resolved in my repository, causing confusion as I didn't realize gnodev was using the code from the examples folder.

After discussing with Leon and investigating further, I realized that gnodev was conflicting between the two packages due to the same name, causing it to sometimes pick the outdated package.

It would be helpful if gnodev could analyze the current package/realm and, if it finds a package with the same name in the examples folder, issue a warning. This would prevent confusion and ensure the correct package is used.

leohhhn commented 2 months ago

@gfanton remember when we discussed this? It has claimed its first victim

deelawn commented 2 months ago

@Molaryy can you see if it works if you use gnodev's -root flag to point to the directory containing the examples/ folder with the changed realm code you want to load?

leohhhn commented 2 months ago

@deelawn the issue is a bit different;

By default, gnodev loads the examples folder. Say, this contains p/demo/avl.

Then, a user might open up a completely different folder outside of the local copy of the monorepo, and create a package with the pkgpath p/demo/avl, and running gnodev . to deploy it, thus creating a conflict. The issue here is that gnodev does not handle this case very clearly, ie the load order is not explicit to the user. The issue @Molaryy had was that he was changing his code in one of the two places, but gnodev was watching the other one, where the code was not being changed.

gfanton commented 2 months ago

I see. I'm currently working on changing the way packages will be loaded in gnodev by implementing a lazy loading approach. First, to only load needed packages, which will improve reload speed (by a lot). Secondly, to be able to choose a different backend. For example, not targeting the example folder but a chain itself. I will keep what you describe in mind and find a way to avoid confusion as much as possible.

leohhhn commented 1 month ago

@gfanton for this specific case, I think that if the user specifies a local path for a package to be loaded, that one should take precedence over the gnohome one. Also, there should be a clear message to the user that a duplicate pkgpath was found, and that the specified path was loaded instead of the gnohome one.