Managing local libraries and workspace and publishing libraries


#1

Is there a way to delete unwanted libraries and projects that isn’t going to corrupt my XOD workspace? I don’t see a delete option for either. Renaming a project just creates a new one rather than renaming the old (which is a nice way to copy a project, but not really renaming it).

I don’t see a way to review a library without adding it to my workspace, and now I can’t delete the ones I don’t want.

I couldn’t find any instructions for uploading or downloading libraries, or how to create one to upload it. I was trying to download from the webpage, but could only see a node list/description. I finally took a chance on File > Add Library and had to add explicit library; search didn’t appear to work.

I took a guess at publishing libraries. Looks like you create a project that will be your library name, then add nodes. Since my nodes were in other projects, I had to copy them over and remember to copy descriptions and C++ code separately. After a couple attempts to get config correct, I was able to publish. Now it looks like I need to download my own library to use it, but keep the original project to update the published library. It would be nice to know if there were any conventions I missed, or easier ways to do any of this.

Since I will probably make updates to my library in the Added Library copy for testing, it would be nice if there was a way to re-publish from there (though obviously I should only be able to re-publish my own).


#2

Yes. Not very obvious, but you can go to $HOME/xod/__lib__ and delete the directory of a library you’re no longer interested in.

Oops. That’s a bug

Yep, it still a documentation TODO. Will write it down soon.

That’s right. And the search is not implemented yet. You get a single item suggestion if a library name typed in 1-to-1 match an existing library.

Yep, that’s cumbersome a bit. Currently, we have two possible workflows:

  1. Your project is a library at the edge of development. Use additional patches to test what you just created or changed. In your any other project “File → Add Library” just like anyone would do. Since you’re confident in your library because you tested it locally on the previous step, there should not be publish—test—does not work—fix—publish—test—does not work… problem
  2. Start the library as a regular project, make OS symlink from $HOME/xod/__lib__/my-username/my-library to $HOME/xod/my-library, evolve it as necessary, publish a new version when ready

BTW, if you ever need to duplicate a patch completely, you can do it on file system by moving/copying/renaming its directory. We designed it to be safe.


#3

bummer…doesn’t look like Window’s shortcut works for this…
I guess I could edit xod/lib/my-username/my-library and copy it to xod/my-library when I’m ready to publish.

That is good to know. I was worried I would corrupt whatever was stored in .xodworkspace (but it looks like an empty file…)


#4

Oops. I meant symlinks, which are surprisingly not so simple on Windows, but nevertheless, they work.

Yep, it will work although boring a bit.

.xodworkspace is just a marker meaning “this directory is a XOD workspace”. Very possibly we’ll abandon it in one of the future releases.


#5

Ah…I did not realize Windows had added real links. cygwin (Linux shell for Windows) ln command didn’t work, but mklink /J from the article you linked to does.