Vvvv Projects - self contained vs. global package repositories

[u7angel]

not sure how everyone is working but the current way of how gamma is saving bits and pieces is creating continous problems for us.

when we work with beta, unity, unreal or cables, everything belonging to this project is in the project folder. all assets, every plugin, package and in case of beta, even the software. this makes it a no brainer to switch machines, let the creatives checkout the state of the software, deploy the software on to the release machine.

we seem not to be able to establish the same workflow with gamma. a simple websockets bridge project, which worked in university, didn’t work on the machine in the office. confusing error messages saying the websockets package is not installed but the nodes are there…or the other way round. and i’ve never messed with any settings. i would expect when i checkout a patch with no special custom libs of my own, that it just works on a second machine, without doing some black magic.

ok, second case. bjoern did a gamma project for us, julia tried to follow the progress of this project by pulling the git repo. having an identical vvvv installation and also had massive problems getting it to work. It never fully worked on her machine and we gave up. at least the export worked on the release machine.

i really would like to see a way to make projects self-contained. no additional package installation on every machine, no magic auto installation. some way to put everything needed into a folder with local references.

having many things related to a vvvv project (sketches, packages) scattered on the hard disc is a bad idea in my opinion.

and please, don’t regard this as a rant but really a cry for help. i really want to work with gamma next year in a bigger project but confidence due to the many weird behaviours is not high.

[andresc4]

I am on a similar situation, but I just because I am quite slow to get use to this new paradigm compared to beta, I don’t claim to be a issue of the design of the new VL, In my case I am sure its me not getting the logic well, many times I was helped out via forums or chat, and many times I felt super stupid not seeing the solution that was just in front of me all the time.

I would suggest to describe the issue you had with your project, upload minimal code to recreate the issue, and for sure people here will help you out to understand what was the problem. In my case 99.9 of the problems were my fault, and 0.01% was me asking for things that do not exist yet

[u7angel]

hey andresc4,
thanks for your kind words.

this is more a feature request, solving a workflow problem in our studio. apart from actual glitches, our creatives who inspect the vvvv projects should not be forced to do any package management. just pull the project and run it. which works if everything is in one folder/git repo. with the global nugets folder, its complicated, to say the least.

99.9% vs. 0.01% ? i keep hitting stuff outside of this range :) i had an old websocket nuget in the nuget folder and checked out a websocket project relying on a newer version of this nuget. the result, gamma states websockets nuget is present but nodes are red, without an informative message what went wrong. i had to manually compare nuget versions. and this is just one tiny project with one nuget. since we switch PC all the time with most likely very different global nuget folders, we are doomed (:

hence self-contained project for the rescue :)

[andresc4]

I can try to say what I would like, but for sure this words should be taken from a non experience dev in data structures, and logic… that being said, I would love to see some way of knowing all the referenced files+locations of a VL document… So if I want to “move” this document to a different PC, I know what files I need

Lets say that D:\MyProject.vl is using
D:\MyProject\helpers\myNetworkingStuff.vl
D:\MyProject\helpers\myAnimationStuff.vl
C:\Users\myPc\AppData\Local\vvvv\gamma\nugets\NetMQ.4.0.1.6

I can keep track of the “project” source if I put a copy of each file inside \MyProject and I also know that this projects needs a specific nugget, so far so good…

But I having the same problem over and over, I have a dir in witch I leave all the wrappers for my own stuff , like D:\VLStuff\helpers\myAnimationStuff.vl
and I keep working on “myProject.vl” and sometimes I realize that I made a new animation module, I move all those nodes from “myProject” to “myanimations” and that helper document is “shared” among other projects, but sooner or latter ( most likely sooner ) I loose track of all the documents that I am using, and until I don´t run the app on a different Pc I don´t realize what is missing.

I guess that a workaround would be a way to list all the dependencies, and to so some kind of "export source + dependencies " to a specific dir, and have a folder with all the necessary files copied to that folder, but the main vl document will need to either look for the file in the old directory, or in a specific folder like “/copiedDependencies”

Still I usually make the mistake of doing modification on the nugget folder itself, and latter on ( I realize of this because I use Acronis very often ) I go back to a snapshot of a specific time of my C drive, and after opening the same project, things are missing / broken

Again, this is my own list of doing the things wrong, this is not the devs fault, but I guess that knowing the “common mistakes” of some users may be helpful to either think if there is a better workaround, or if just a new documentation or video tutorial is needed to solve this common mistakes.

[catweasel]

I’ve just read through the riot chat, and it seemed to say that if you have a package in global nuget, and in a user nuget, that they will clash? Isnt the point of the user nuget that it should override the global, otherwise how would you work on a nuget to update it?
It kind of feels like we need a heirarchy of nuget where you could have a project nuget folder (myproject/nuget) that should be referenced in preference (ideally just by having the folder there, no bat) to either a user nuget or global one and user should take preference to the global one, if specified, then you can have a local nuget that you can work on, if your project needs additions/alterations, without breaking other projects or the original nuget. (This probably contravenes programmers creed, but from a vvvv point of view, I have always added stuff to modules that I need per project, and like u7 always have a local vvvv install as well to make sure its the right release, with all the right addons and alterations!)
Reading Andres comment above, he suffers the same problems. vvvv was for non programers, and VL isn’t quite as kind I think.
Also I have occasianly come across having a shader or patch with the same name as in VL defaults, probably from copying things over, and it throws an error not knowing which to choose, we should be able to choose which to use, and have a option to rename local clashes.
+1 for Copy to project, would be a great feature.

[u7angel]

@catweasel

vvvv was for non programers, and VL isn’t quite as kind I think.

interesting thesis, i think in terms of nuget management, its not the stupid non-programmers but bad ux design / incomplete feature. if the nuget folder would be part of the vvvv installation, it would make things easier… apart from version conflicts which still need to be indicated

[andresc4]

maybe implementing something like “GammaSettings.cfg” next to the executable could define where the nugget should be look and installed. By doing this, we can go back to the old beta logic, you know that “its all in that folder” ?

[ravazquez]

Interesting discussion!

I am not sure how much this adds to the topic, but in the past I have had issues with old and no longer available nugets. Also scenarios in which we needed nugets to be resolved in offline scenarios.

One possible solution for these cases (and potentially for yours) is to create a custom nuget package source/feed (essentially a directory with all your nugets) and reference it in your nuget configuration file.

In this way, you can have a local copy of all your dependencies in the location of your choice (it can be a git repo you pull as well).

Although it’s not an ideal solution, I did manage to get it working successfully.

Here is some documentation on how to tackle this: Setting up Local NuGet Feeds | Microsoft Learn

Just my 2 cents.

[antokhio]

Well I just copy %whatever%/romaing(or local)/vvvv/gamma-preview/nuggets (or something like that) on usb… I guess it would be better to change gamma installation path to c:/vvvv/gamma_version and to store nuggets under c:/vvvv and not that inaccessible path

[joreg]

answering @u7angel initial quest: as a quick “fix”, latest previews now have a new commandline parameter. e.g usage:

--nuget-path C:\MyProject\nugets

setting this, replaces the default global nugets directory. this allows you to set the path to a directory that is part of your project. please let us know if this improves your workflow.

clarification: how does this differ from the “–package-repositories” commandline parameter? specifying a custom nuget-path, ignores the default global path, while specifying package-repositories adds to the search path and also allows multiple paths to be specified.

@catweasel

if you have a package in global nuget, and in a user nuget, that they will clash?

this is not the case. nugets found in paths specified by the “–package-repositories” commandline parameter are taking precedence.

[andresc4]

@joreg I think this is a good solution to the problem described on this thread, thanks!
2 question regarding this… is is a good idea to make some think like settings.cfg next to vvvv executable to avoid calling that commandline by separate ? maybe iin the future there are more settings that can be appended there
Also, is it possible to reference that nugget directory inside vvvv folder, without need of a “fix” reference to a specific location?
By doing this, just copying the vvvv folder can “fix” the concerns described here, when moving the whole project to a different pc

maybe its a realy bad idea because a lot of things that I am not aware , let us know
thanks !

[andresc4]

having a /include folder next to the vl.doc , so when you open the doc, automatically includes all the .vl dependencies inside that folder sound like a bad idea?
I miss the old “root” patch