Enhancements: verbosity, flat, versions, contradictions

[ZvikaZ]

Few possible enhancements:

1: Currently GWS is very verbose. It's nice, but if there are many repos, and it's called as part of other script, it can be too verbose... I think it's better to have 3 level of verbosities:

• High verbose (current):

  $ gws update
  base:
                              Already exists
  verif_tools:
  
                              Cloning…
                              Cloned

• Low verbose: (one line for each component)

  $ gws update
  base:                                     Already exists
  verif_tools:                              Cloned

• Quiet: (only print if something goes wrong)

  $ gws update
  $

The user can have default verbosity, set either in an environment variable, or in ~/.gws.rc file; and the verbosity can also be changed in every run of the script with a run time flag.

2: "Flatten recursive" tree support. Suppose we have a repos tree, like this:

a
├── b
└── c
    └── d

Where 'a' is top repo, which reuses repos 'b' and 'c'. Repo 'c' in turn, reuses repo 'd'. I'd like to have all repos 'flat' under the top repo, so effectively it would be treated like this:

a
├── b
├── c
└── d

a's .project file doesn't mention 'd' explicitly, but all GWS commands, from everywhere in this tree, will treat 'd' as 'brother' of 'b', and it will be located directly under 'a'.

This behaviour should not be under user configuration (opposed to verbosity configuration) but a property defined in the .project file.

Maybe something like this: lib/tools | https://github.com/nice/tools.git | flat - would treat everything mentioned in tools' .project as if it was mentioned in my .project file.

3: Versions support - the ability to specify that some repo should be in a specific version (or branch, or tag).

I know it can be modified in each repo individually, but I'd like to make that info (sometimes) official, so it can be part of the deployment. Specific version of .projects.gws brings specific version of some repo.

lib/tools | https://github.com/nice/tools.git | release_013 - would fetch tools repo, and take the tag 'release_013' This will probably make use of gws update to update the repo to that version.

4: An interesting complication is the combination of my suggestions 2 & 3. Check this tree:

a
├── b
└── c
    └── g
        └── b

What happens if we flatten this tree, and 'a' requests 'b' to be 'r_013' while 'g' requests 'b' to be 'r_014'? There are many possibilities here. I think the best solution would be to issue a contradiction warning, and let the requirement of the higher repo in the hierrarchy to win. (i.e., 'c' will win 'g' (if it contradict), and 'a' will win 'c' and 'g')

• I'm willing to try to implement these ideas in Python, or some other common language, but I don't think that I'm going to learn Rust anytime soon...

[StreakyCobra]

Thanks for taking time to write this! I'll consider it when, and if, I continue to work on this project :-)

[emlun]

Thank you for your input!

1. This will be somewhat alleviated with the new --hide-clean command line option introduced by #30. Does that cover some of your needs?
2. I'm afraid I also don't have the time or will to develop such a feature in bash. It would have to be in a reboot in a more capable language.
3. This has been discussed in #15, and it would be difficult to squeeze the setting into .projects.gws without breaking existing project files. It's probably possible, but it would likely require some awkward fidgeting to parse correctly. Again, I'm afraid I can't invest the time to work out how to do it without breakage - but please do submit a PR if you find a way to do it.
4. (Irrelevant without 2.)

[StreakyCobra]

it would be difficult to squeeze the setting into .projects.gws without breaking existing project files

The format started as a simple list, then have been hacked to fit the need of different remotes, it is far from optimal. Gws is still in <1.0, so breaking the file format could be an option if needed.

Someone once suggested to use a standard file format, like YAML, instead of this custom format. This would offer syntax coloration in text editors, and would allow to parse it easily in other languages. I like the idea, and there are some code to parse YAML from bash [1] [2].

I'm just saying this FYI, so you have this in a corner of your mind if the need arises :-)

[emlun]

Reviewing this again, I also think git submodules already solve (3) well enough. Migrating to YAML or something similar would be nice of course, but I'd say both of these are out of scope for this incarnation of gws.