Tony Narlock

> That way we could have "sync" as the "normal sync", maybe "import" or "scan" for your mentioned idea of scanning an existing folder structure and generating a config out...

> who knows, if you bring the current `master` codebase into the new structure (like moving the current "sync" code into its own file and proposing the structure and invocation)...

Noted on the other account Also, while the development loop will be the same, in the coming weeks I may make some refactors between https://github.com/vcs-python/libvcs/ and https://github.com/vcs-python/vcspull/. I haven't taken...

> Btw, is all this documented in some markdown file in the repo for other people for local development? It might help others to jump in and contribute to this...

> who knows, if you bring the current `master` codebase into the new structure (like moving the current "sync" code into its own file and proposing the structure and invocation)...

It's true. I'm using an abbreviated version policy, I should add a note we don't follow sem ver and APIs are unstable. this doesn't have as many users as say,...

@aschleifer > @tony in regards to developing this: Is there already a method in the code to write a loaded config back into the yaml/json config structure? > > Obviously...

@Segaja Part of me wishes I never added those `extract_repo`/enrichment things. If it was just purely the dictionary structure, with the exception of [`expanduser`](https://docs.python.org/3/library/os.path.html#os.path.expanduser)/[`expandvars`](https://docs.python.org/3/library/os.path.html#os.path.expandvars), the code would be _far_ simpler.

I'm deliberating doing the same to [tmuxp](https://github.com/tmux-python/tmuxp). > I agree. Can we rip it out? :D I created #360 to brainstorm a config format that'd work with all purposes

@fwilhe Thanks for the request Makes sense