List/Load Projects

[tokejepsen]

Goal

To make it easier to list and load projects.

Motivation

1. Currently there are no way of listing projects in the database when using the CLI.
2. When using avalon --load, the name is taken from the current working directory, so there is no way of loading a differently named project.
3. When using avalon --load it would be nice to display available projects to load.

Implementation

1. Add a command avalon --projects. Or some other flag?
2. Make avalon --load accept a project name input, so loading a project will be avalon --load myProject. This input could be optional to allow existing behaviour of loading the name of the current working directory.
   Lastly could also have the command be something like avalon --load --project_name myProject. Although personally I feel its unnecessarily long.
3. The current message when not finding a project is:

Loading .inventory.toml and .config.toml..
'mySecondProject' not found, try --init to start a new project.

Suggestion:

Loading .inventory.toml and .config.toml..
'mySecondProject' not found, try --init to start a new project, or load a project from the database. 
Projects:
- myProject
- mySecondProject

[mottosso]

Add a command avalon --projects. Or some other flag?

Would prefer avalon --ls, that is also what you use in Maya maya.api.ls() and for assets avalon.api.ls().

Make avalon --load accept a project name input,

The only problem with that is, what do you do about the current working directory? E.g. you are in /batman but type in --load spiderman.

[tokejepsen]

The only problem with that is, what do you do about the current working directory?

Throw an error message about loading a project in the directory that already contains *.toml files?

Or is avalon --load supposed to fetch updates from the database and write to the *.toml files?

[mottosso]

Yeah, --load writes to disk what you've got in the database, for you to edit, and then submit with --save.

[tokejepsen]

Could we throw an error when loading a project that is not named the same as the current *.toml files?

[mottosso]

--load creates the toml files if they don't exist. Or how do you mean?

[tokejepsen]

The only problem with that is, what do you do about the current working directory? E.g. you are in /batman but type in --load spiderman

If you are in /batman and use avalon --load spiderman, you should get the spiderman project, no matter the parent directory's name.

If /batman has toml files we would need to make sure the project name matches with spiderman or throw an error.

[mottosso]

Happy to try that.

[tokejepsen]

Just looked into the toml files, and there is no record of the project name in the toml files. This means we cant compare the desired project name to load, to what exists on disk.

How should we proceed with this?
Looks like you could currently rename a project folder to an existing name in the database and overwrite the toml files without knowing you are changing/overwriting existing data on disk.

[mottosso]

Remind me again what the problem was loading the project based on the current working dir, and having a --ls to list what working dirs you can work in?

[tokejepsen]

If you want a folder named different from current working dir. For example "my_project" folder, but load "My Project".

[mottosso]

I see what you mean, and it should be possible, but perhaps the CLI isn't the best tool for it. I'm a little weary of letting the CLI become too feature rich, and would rather it remain a fallback for when a more feature complete GUI or web interface fails. Basically, I think the effort is just but that it may yield a greater return of investment elsewhere.

I'm not entirely confident about that and could see it both ways. We could also look at making the CLI more central as a CLI would be quicker to develop, as GUIs invite a lot of complexity.

What do you think about that?

[tokejepsen]

What do you think about that?

Yeah, I did tend to find that I need to change both avalon-setup and avalon-core, when doing these changes. The CLI in avalon-setup seems to be a mirror of the inventory in avalon-core.

I personally dont have enough of an overview of Avalon to know where and how this should proceed, but I'm up for working on it.

Currently though I have everything for this issue ready, except that you can overwrite data on disk if you load a different project. This was doable before as well, but required you to change the name of the current working directory instead of just a flag to avalon --load.
Should we look into merging these changes, before proceeding with the CLI work?
We could also just merge 1 and 2.

[mottosso]

Should we look into merging these changes, before proceeding with the CLI work?

Yes, let's do that.

The CLI in avalon-setup seems to be a mirror of the inventory in avalon-core.

Yes, not a mirror per-se, but rather forwarding requests to it.

What I've tried to do is keep functionality as local where possible; the inventory in core is is used internally by the core library, and the CLI is like a GUI for it. Calling upon it where necessary.

I would consider making it python -m avalon.inventory --load instead which is more explicit and is effectively the same thing. In fact, that's where you should add these features, as the CLI merely forwards requests to there.

avalon.py was mostly intended for the tutorial, to avoid mention of internal Python modules, or even Python as it is also an executable. Not 100% about whether it's the right thing to do.

[mottosso]

For completeness, to modify the argument for --load, this would be a good place to start.

[mottosso]

Just getting my bearings, it's not the most obvious system, but it's all driven by environment variables up till the current project. From there, any command is relative this project.

For example, io.find_one() is what you use to search the database, and it will look for an item in the current project, which is defined via AVALON_PROJECT. I found that the CLI is configuring that variable here

I think that might be what you're looking for. Basically, if no path is passed via the CLI, look at the current working directory.