I recently encountered a bug in some other package
I need to edit the patch to see if it contains a bug. But the compiled package, whatever I changed, made no difference. It felt like I had to force compilation, but that didn’t work too (“Compile source packages”). The “no cache” menu item seems to have worked, but im not sure. Then I have a question, what is the right way to proceed if the bug is in compiled packages? And most importantly, can I also compile my own packages?
I have seen this article and read it several times, thank you.
I still have questions:
What if I don’t want to clone, but want to fix a small bug or make a small change? Can I change something in an existing package without copying anything and be sure it will recompile? Or does this only work for packages where I don’t need to compile a C# solution?
I was eventually able to fix the bug and run the library with the fix, but I’m not sure I did it right because this method is not described in this article. Maybe add more about No Cache to the article?
I’m also very interested in the fact that I’d like to be able to continue using the package compiled after editing to speed things up (the same “fuse” is quite heavy and compiles on the fly causing performance degradation).
Can I change something in an existing package without copying anything and be sure it will recompile?
Even though we don’t recommend it and strongly encourage you to work on the source package, you can edit a nuget package if need be:
Mark that package as editable with --editable-packages Foo.Bar
Make your changes
Restart vvvv without the --editable-packages command line argument but with the --nocache flag to ensure all packages get re-compiled and the internal cache updated.
Restart vvvv once more without any flags
Or does this only work for packages where I don’t need to compile a C# solution?
A nuget package doesn’t come with a C# solution. Not sure this is related.
I was eventually able to fix the bug and run the library with the fix
You most probably missed step 3). Our system assumes that nuget packages don’t get modified by the user. It therefor does not compare checksums on startup which it would do if you’d follow the recommended source package workflow.
Maybe add more about No Cache to the article?
Not sure we should encourage this workflow any further in our main documentation. The probablitly to lose work / introduce nasty bugs is super high, especially if your changes happended a few weeks back.
I’d like to be able to continue using the package compiled after editing to speed things up
It should like outlined in step 1-4
where does “compile source packages” come from
This was an older concept and should be removed from the launcher. It was replaced with the editable packages concept.
Well because it’s about little details already, I should add: the startup time of a system loading only nuget packages should be slightly better than one loading only source packages because of the before mentioned checksum computation. What I remember this is between one and two seconds. The final result is the same, it only takes a little bit longer to get there.
@Elias What does “Use repos” do?
What difference does it make?
Is this necessary when I download not a nuget but a repository from github? Is there a significant difference between repository and nuget that you described above?
“source packages” = repos?
nugets is kinda prepared source packages?
Just chiming in to answer the Launcher related question : the Use Repos checkbox starts vvvv with the --package-repositories arg and appends the folders you have listed in the Package Repositories section of the Launcher
I think I did the right thing here
But I still don’t have a “read-only” bar.
When I open some nodes via “open”, it looks like a normal patch. It wouldn’t bother me if it weren’t for one problem - when I close such a “package” with ctrl+w it closes the whole patch, not just the package. Plus I still don’t understand if it’s compiled or not?