Hm.. I would propose a structure like this:
~/.nuke/
nukepedia/
downloads/...
tmp/...
nuBridge/...
tools/
mypkg1/
v1.2/...
v1.3/...
otherthing/
v0.4/...
(stealing the structure somewhat from the
https://github.com/Homebrew/homebrew package manager)
Then, for example when user installs the "autoroto" tool:
1. Download the uploaded file to
~/.nuke/nukepedia/downloads/autoroto_v1.1.zip
2. Extract contents of archive somewhere, maybe
~/.nuke/nukepedia/temp/autoroto/v1.1/
There would be a few install procedures:
a) Standard but non-Nukepedia specific structure
I would suspect there a lot of uploads which follow the structure like:
autoroto_v1.1.zip/
autoroto_v1.1/
init.py
menu.py
gizmos/
autoroto.gizmo
etc.gizmo
docs/
thing.pdf
In this case the install procedure would be to simply copy the contents
of the "autoroto_v1.1/" directory into
~/.nuke/nukepedia/tools/autoroto/v1.1
Then at startup time, the nuBridge could would add the above directory
onto the NUKE_PATH.
b) Unstructured uploads
For a random .gizmo file, or maybe a zip containing a bunch of .gizmo
files etc - almost same - simply copy the .gizmo file into
~/.nuke/nukepedia/tools/autoroto/v1.1/autoroto.gizmo
and add it to NUKE_PATH.
From here you could, optionally, generate a init.py or menu.py file
based on the file names, and metadata from Nukepedia (like category)
c) Custom install procedure
It would be possible to create a custom package format similar to RV's,
but I'm not too sure about this - it seems like the "folder with menu.py
or init.py at root" pretty much covers anything you might do. The custom
format might allow things like packages depending on others.. but this
quickly becomes a very difficult problem if you let the scope get too big.
The above file structure would have a few benefits:
1) Removing a version is simply case of deleting either the package
directory or a version. This can be done both manually in file-manager
or within the nuBridge UI.
2) The "active" version can be chosen dynamically.
By default you would just load the highest version (using semver via
something like https://github.com/k-bx/python-semver probably).
However you could also do some interesting things, for example implement
a "working environment" configuration which locks down specific versions
for a project.
Say you might have a "somefilm" config like:
autoroto==2
jops==1.2
myutils
When you active this working-env, nuBridge would the latest 2.x version
of "autoroto", jops version 1.2 specifically, and the latest version of
"myutils".
This format could also be used to install the required packages using
the same logic.
(this is pretty similar to the Ruby "Gemfile"
http://bundler.io/v1.5/gemfile.html and the Rust language's package
manager's dependency section - http://doc.crates.io/manifest.html )
I think my description might be longer than the code to implement it :P
Plus I did gloss over possibly having a platform section in the
directory structure for platform-specific plugins (like having
"~/.nuke/nukepedia/tools/autoroto/v1.1/mac,linux/" and "v1.1/windows/"
side-by-side)
On 28/01/16 14:41, Frank Rueter|OHUfx wrote:
Yes, that is indeed the biggest challenge.
At the moment I am keeping the "installation" as simple as possible -
and as transparent as possible.
There will be a folder in ~/Nukepedia where the downloaded files are
stored "as-is". Then the installer will try to make sense of them.
In the simplest case it's a gizmo file that just needs to be copied into
the folder structure which will add itself to the plugin path.
E.g.:
if you download a gizmo file it will end up in
~/Nukepedia/downloads/MyTool.gizmo
The installer will then look at it and decide that it can "install" this
file by simply copying it to ~/Nukepedia/gizmos/MyTool.gizmo
Which means you end up with copies of the tool, but only one is actually
in the plugin path, while the other represents the original file from
Nukepedia.
So with a zip file containing a single gizmo, you would end up with
those two files:
~/Nukepedia/downloads/MyTool.zip
~/Nukepedia/gizmos/MyTool.gizmo
Any file that cannot be installed because it's not clear how to (all
python code for example), will just be downloaded and the user will be
given a button to take them to the download location for manual
installation.
I will assess existing zip/tar files in the database and see if it's
worth trying to unpack things. E.g. if there is nothing but a gizmo file
inside a zip file, I might as well do that automatically as well as
mentioned above.
For the first release I probably wont go further than that, but for the
future I am planning to design some sort of packaging system, kinda like
RV's.
Once we have a package design figure out, we can create a new upload
process on the website to facilitate the upload of tools that conform to
the packaging and therefore can be installed automatically. Maybe we
will have a sort of upload wizard that guides an author through the
required steps and packages the files on the server.
We might even create a PySide app to enable people to test and upload
tools without the browser. Not sure yet.
As for the package design, rest assured that I will consult all you guys
for input :)
In fact, we might as well start the brain storm here and now if anybody
would like to contribute?
The obvious starting point would be to have a zip file that contains the
actual tool file(s) and some sort of text file (json, xml...) to provide
required info for installation (about python code, icons, etc).
Any thoughts?
Cheers,
frank
On 01/28/2016 04:45 PM, Ben Dickson wrote:
Hmm, how does the installation procedure work? There is quite a
variety in how things are uploaded (e.g directly uploading *.gizmo
file with "add the the following to your menu.py, or uploading tarball
with *.gizmo and menu.py, tarballs with different folder structures, etc)
For example, does it just extract the uploaded file into it's own
directory, and automatically add this directory to the Nuke plugin
path? Or something more elaborate?
On 27/01/16 06:53, Frank Rueter|OHUfx wrote:
With over 1000 tools in the database it's time for something like this:
http://www.nukepedia.com
--
ohufxLogo 50x50 <http://www.ohufx.com> *vfx compositing
<http://ohufx.com/index.php/vfx-compositing> | *workflow customisation
and consulting <http://ohufx.com/index.php/vfx-customising>* *
_______________________________________________
Nuke-python mailing list
Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
_______________________________________________
Nuke-python mailing list
Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
--
ben dickson
2D TD | ben.dick...@rsp.com.au
rising sun pictures | www.rsp.com.au
_______________________________________________
Nuke-python mailing list
Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
