Config format

[tony]

Eliminate shorthands

<folder>:
  <repoName>: '<repoUrl>'

• This would need to be a 2.0.0 thing
• 2.0 could be released today if I wanted to, but we'd end up having versions like Firefox or Chrome does. Eventually we'd end up at vcspull 42.0.1

One config format

• Future-proof: Has to work with all theoretically all vcs and copying systems: git, svn, hg, scp, rsync, http, whatever
• Work immediately out of the box, focus on code clarity:
  • Pass into

    GitRepo(path=pathlib.Path('~/work') / pathlib.Path('libtmux'), **options)
    SVNRepo(path=pathlib.Path('~/work') / pathlib.Path('MySVNProject'), **options)

• Make config file mutations like Feature request: command to add new repository #333 easier

~/work/:
  libtmux:
    vcs: 'git'
    options:
      origin: 
        url: 'https://github.com/vcs-python/vcspull.git'
  libtmux_mirrored_remotes:
    vcs: 'git'
    options:
      origin: 
        fetch: 'https://github.com/vcs-python/vcspull.git'
        push: 'git+ssh//git@github.com/vcs-python/vcspull.git'
  MySVNProject:
    vcs: 'svn'
    options:
      url: http://unladen-swallow.googlecode.com/svn/trunk/

[Segaja]

Do we really need to rework the config structure? As far as I see the extract_repos() call just adds some information, but I think the current sync could work without it.

[Segaja]

Also in your example the git config is a bit redundant if fetch and push urls are the same. Is that explicit to make the coding easier?

[tony]

Do we really need to rework the config structure? As far as I see the extract_repos() call just adds some information, but I think the current sync could work without it.

I'd like the make sure the code more transparent and clear - maybe you are onto something. Perhaps make a PR?

[tony]

Also in your example the git config is a bit redundant if fetch and push urls are the same. Is that explicit to make the coding easier?

You're right

git remote allows git remote add <name> <url> . This populates both the push+fetch:

git remote -v
origin  git+ssh://git@github.com/vcs-python/vcspull.git (fetch)
origin  git+ssh://git@github.com/vcs-python/vcspull.git (push)

I added a variant for remotes:

~/work/:
  libtmux:
    vcs: 'git'
    options:
      origin: 
        url: 'https://github.com/vcs-python/vcspull.git'

Long form:

  libtmux_mirrored_remotes:
    vcs: 'git'
    options:
      origin: 
        fetch: 'https://github.com/vcs-python/vcspull.git'
        push: 'git+ssh//git@github.com/vcs-python/vcspull.git'

[tony]

My backstory is back when I created tmuxp/vcspull/etc years ago. I took a lot of inspiration from a config management tool called salt states, see their git.

The more "magic" and "hydration" there is, the more pain it is to debug.

you're feedback is very welcome. I'm easy either way as far as what the structure looks like (or whether it changes substantially)

[Segaja]

Do we really need to rework the config structure? As far as I see the extract_repos() call just adds some information, but I think the current sync could work without it.

I'd like the make sure the code more transparent and clear - maybe you are onto something. Perhaps make a PR?

I'm trying. I'm not sure if I want the path expansion to happen during config loading or when we loop over the entries anyway to update them.

[tony]

I'm trying. I'm not sure if I want the path expansion to happen during config loading or when we loop over the entries anyway to update them.

Chicken or egg.

[Segaja]

~/work/:
  libtmux:
    vcs: 'git'
    remotes:
      origin: 'https://github.com/vcs-python/vcspull.git'
  libtmux_mirrored_remotes:
    vcs: 'git'
    remotes:
      origin: 'ssh//git@github.com/vcs-python/vcspull.git'
      fetch: 'https://github.com/vcs-python/vcspull.git'
  MySVNProject:
    vcs: 'svn'
    url: http://unladen-swallow.googlecode.com/svn/trunk/

[Segaja]

We should also think of adding some kind of config validation between reading the config from the file and actually using it.