Thanks Ben. Great ideas there. A lot of this is similar to thoughts I
have already had, which were mostly dealing with the balance of a
complex directory structure for the sake of flexibility (such as
switching active versions as you mentioned), and simplicity/transparency
for the user.
One thing to consider is that I didn't intent the nuBridge to be a
facility tool, but rather a personal sandbox for quick evaluation of
downloaded tools. When a tool is considered useful and safe, I would
like to leave the facility/show install up to the respective person.
This decision stems from trying to not be responsible for other
company's tool pipeline as well as political reasons (the afore
mentioned grilling I got by some, which verged on threats of
blacklisting the nuBridge straight away if it encouraged people to
install stuff in the facility pipeline).
I will mull his over some more though as it sounds quite nice I reckon.
>> it seems like the "folder with menu.py or init.py at root" pretty
much covers anything you might do
Yes, but I personally would like to not just source any init/menu.py
delivered by the author, as every tool is going to end up in
god-knows-what menu. There just wouldn't be any consistency and it'll be
like a Easter egg hunt to find stuff in the UI.
Instead I am more hoping to have a simple config file to provide
essential install info (e.g. the menu command itself and the required
imports), and assemble the actual menu commands on the fly into one
"Nukepedia" menu (and sub menu that correspond to the tool category), so
the user always knows where things end up after the install.
Thanks for the thorough rundown though, it's a great point of reference
to have for this discussion.
What do others think?
frank
On 28/01/16 8:54 pm, Ben Dickson wrote:
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
--
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
