be init

[mottosso]

goal

Generate skeleton from template.yaml

motivation

be dynamically allocates directories as they come into use. But sometimes it can make sense to statically create an entire hierarchy up-front.

Related

• https://github.com/mottosso/be-presets/wiki/skeleton

[mottosso]

The problem with this approach is the lack of information available through templates.yaml and inventory.yaml. Only the top-most layer could ever be created, and in cases the {user} variable is provided, it would only ever (accurately) be able to provide a single user within a hierarchy; the currently logged on user.

One alternative is to (1) mock up subsequent levels, such as a rigging directory to a top-level ben asset, and several users, like marcus, richard and peter. The problem with this however is that the generated hierarchy would be partially inaccurate/useless to the user, as it is unlikely that the mocked up items would ever be used.

Another alternative is to (2) support more data. To allow users to not only specify an inventory, but also tasks.yaml and users.yaml. With this additional data, a more accurate hierarchy could be automatically created. The problem however is never knowing whether the one additional layer of inventory is enough; for example, rigging may not be the next level, instead shot may be the next level of sequence, for which an additional layer, e.g. animation would be required.

To solve this, the additional layer could be hierarchical. It would however limit their use to be init and possibly validation and prevention of the creation of unsupported directories.

[ghost]

The third approach seems the best one, however I'm not sure I see the use of a users.yml anymore except for setting directory access or assigning task for users. Or maybe I just don't see the hierarchy that would be generated.

Either way, to make the hierarchy somewhat future-proof, something like a be update would be good if a change to the structure is made in the templates.

[mottosso]

however I'm not sure I see the use of a users.yml anymore except for setting directory access or assigning task for users.

Yeah, this is the problem, it wouldn't be of any other use at the moment.

Initially, I did have plans on also including a lightweight task-management system.

hulk/users.yaml

marcus:
- bruce modeling
- greenBruce modeling

thomas:
- bruce rigging

peter:
- seq03 1500 animation

Such that users would be limited to starting a task they have been assigned.

Added a topic about this here.

• https://github.com/mottosso/be/issues/36

Either way, to make the hierarchy somewhat future-proof, something like a be update would be good if a change to the structure is made in the templates.

This just blew my mind. This is amazing!

I wonder if this actually could work in an intuitive enough fashion to be useful. Projects can get quite large, and files can remain in use even after everyone has stopped using them and thus prevent deletion/modification.

Maybe the only safe way to do this would be to first copy the entire project into it's new configuration, and then perform a move of the top-most directory after having successfully deleted the original. Though I suppose the problem here is, again, the sheer size of any potential project and the time it would take to actually perform it.

[ghost]

Yes I agree, another problem for the users would be security. The config file for users should be read-only then.

For the be update part I was only thinking about something like adding tasks or stuff like that, which would not be too hard. But changing a whole folder configuration could be really heavy, and without a database, keeping track of assets (textures, models, etc.) would be really hard, especially for big scenes.

[mottosso]

Yes I agree, another problem for the users would be security. The config file for users should be read-only then.

That's a good point, do you think standard file-system permissions would do? I'm thinking only those with sudo-powers, or admins in general could have write-access.

keeping track of assets (textures, models, etc.) would be really hard, especially for big scenes.

Ah, yes that is also a good point. That could be hard to pull off in a consistent manner. Updating configuration files though shouldn't be a problem, but I wonder how useful this would be in case of updating the template, as the template would from that point on be out-of-date. Updating anything else though could work well I think.

Spontaneously, I'm thinking of embedding a source key in be.yaml upon creating the project.

# Either
source: mottosso/be-film  # Updates would pull from here

# Or
source: mylocalpreset  # Updates would copy from here

And updating could look like as you described.

$ be update spiderman
Pulling mottosso/be-film..
Update successful!

Creating a separate issue for this.