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).
Another question: where does “compile source packages” come from if it is not in the commandline arguments?
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:
--editable-packages Foo.Bar--editable-packages command line argument but with the --nocache flag to ensure all packages get re-compiled and the internal cache updated.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.
I’d like to clarify a few details
If I add some packages as --package-repositories, will they be compiled if they are not --editable-packages?
That is to say, can I expect the benefits of compiling to my own packages, in my own folder?
Yes, in that regard we treat all packages the same no matter whether they are a source package or a nuget package.
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?
Is this related?
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
@Elias I’m probably boring you with questions. But I have checked some of the things I asked about. And either I misunderstood or we have some ambiguity in the application.
When I use --package-repository on my packages (by putting it in a separate folder and specifying it), I don’t get the “this package is compiled, read-only” placeholder.
In this case, is it just an ambiguity and it’s compiled?
Or are my packages not precompiled that way?
Or am I not following some requirement for this package to be precompiled?
The pattern is: --package-repositories Foo\Bar and your main package file would be Foo\Bar\VL.ModelUtils\VL.ModelUtils.vl
PackageName\PackageName.vl is what our system is looking for in any path given by the package-repositories.
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?
Maybe you have this package specified as --editable-packages? In this case they won’t be precompiled, and you won’t see the warning message.
This paragraph from the StandardLib’s README explains the whole thing very well.
@sebescudie nope
I’ve actually been experimenting with this. It happens on other packages too. It turns out to be some kind of ambiguity. Either I’m doing something wrong.
But the minimal example compiles!
We need to investigate this deeper, it seems.
At the same time, the package is added in the same way:
Could this be important:
Hard to say really. Some weired dependencies?
Ahhh there we go! Sorry but library precompiled plus c# project reference is sadly not there yet.
@Elias Thanks, it’s really great that we’ve sorted it out. Thank you so much for your patience.
I’ve been worried.
Let me know when it starts working.
