Feature request: command to add new repository

[aschleifer]

Currently when using this tool one has to edit the config file and then run the vcspull command (maybe with filter on the new repo name) to get the new checkout.

I would propose to add some sort of command where you can do something like vcspull add <repoUrl> which will then generate an entry similar to:

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

in the existing config. would be the folder from which the call is executed Obviously if the already exist it should just add an entry to that block. The should be extractable from the , if not it needs to be passed in the call.

Once this config update was done vcspull should be able to run its normal "checkout/update" logic on that new entry to create it.

That way you can add a new entry in the vcspull config and get the checkout right away.

Any thoughts on this?

Best regards
Segaja

[rogerioefonseca]

I liked the idea, I'm using the tool as well to organize my private repos, and would be nice to not add manually configuration.

And that could work in the other way around as well to remove the entry, haha.

[tony]

This sounds good to me

[tony]

@rogerioefonseca @aschleifer

Unrelated: Do you have any objection to the behavior of the empty command (e.g. vcspull) requiring vcspull sync or vcspull s to initiate a sync? As it stands vcspull automatically syncs, but i'd like to change it to a command list

The old behavior would be possible by making an alias to vcspull sync

[aschleifer]

I personally think it makes sense to have "subcommands" you need to execute. And maybe show a usage if you don't pass the subcommand.

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 of it.
For the current example we could then do "add" for adding one new repo (as described in the description of this issue) and so on.

For code structure it could make sense to also split the code for these subcommands each into its own file. that way it is easier to maintain the code and "see" where what is happening.

[rogerioefonseca]

I like the idea of having a list of commands instead of starting with the principle that it will by default execute some magical command, and having that, I agree with you to add the vcspull sync

[tony]

I will look at this above feedback and also make giving the default command list "subcommands"

[tony]

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 of it. For the current example we could then do "add" for adding one new repo (as described in the description of this issue) and so on.

Noted

For code structure it could make sense to also split the code for these subcommands each into its own file. that way it is easier to maintain the code and "see" where what is happening.

Agreed

I like the idea of having a list of commands instead of starting with the principle that it will by default execute some magical command, and having that, I agree with you to add the vcspull sync

I agree with this sentiment. Next release will move the sync behavior to vcspull sync

[aschleifer]

@tony 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) I might pick up the idea of this issue here and add the new command myself.

Working on the generator script in python got me enjoying python again, so if you don't mind i could implement this "add" feature myself.

[tony]

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) I might pick up the idea of this issue here and add the new command myself.

My first order of business this weekend will be to do that

P.S. If you have the codebase checked out, do you use poetry? You can run poetry shell, poetry install on the project

If you have that setup, does make test work?

If you install entr (https://github.com/eradman/entr), you can also do make watch_test to rerun on file changes

[aschleifer]

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) I might pick up the idea of this issue here and add the new command myself.

My first order of business this weekend will be to do that

Nice, I will watch for changes. Also it might be that my other account ( Segaja ) then interacts with this repository.

P.S. If you have the codebase checked out, do you use poetry? You can run poetry shell, poetry install on the project

If you have that setup, does make test work?

If you install entr (https://github.com/eradman/entr), you can also do make watch_test to rerun on file changes

Right now I have a fork of this repo where I did the changes on, I didn't use poetry yet, but if I get into feature development on this project then I guess it makes sense to get familiar with these things.

[tony]

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 a fresh look at the APIs in a long time

[aschleifer]

P.S. If you have the codebase checked out, do you use poetry? You can run poetry shell, poetry install on the project

If you have that setup, does make test work?

If you install entr (https://github.com/eradman/entr), you can also do make watch_test to rerun on file changes

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 project.

[tony]

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 project.

Yes - and I plan on overhauling / improving it more

markdown: https://github.com/vcs-python/vcspull/blob/master/docs/developing.md
html: https://vcspull.git-pull.com/developing.html