-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: command to add new repository #333
Comments
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. |
This sounds good to me |
Unrelated: Do you have any objection to the behavior of the empty command (e.g. The old behavior would be possible by making an alias to |
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 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. |
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 |
I will look at this above feedback and also make giving the default command list "subcommands" |
Noted
Agreed
I agree with this sentiment. Next release will move the sync behavior to |
@tony who knows, if you bring the current 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. |
My first order of business this weekend will be to do that P.S. If you have the codebase checked out, do you use If you have that setup, does If you install |
Nice, I will watch for changes. Also it might be that my other account ( Segaja ) then interacts with this repository.
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. |
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 |
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 |
more to come, including fixing shell completions. It's there, but broken:
|
Nice work. I will look into it as soon as I find time. But one thing I saw already. You are using a 3 digit version number which implies you are following Semantic Versioning, but actually you are doing breaking changes in a "feature version" (1.10.0). In semantic versioning such change would have been released as 2.0.0 to indicate to people that something breaks. Since you didn't choose 2.0.0 as a version I guess you didn't hear of Semantic Versioning before, which is fine. Just wanted to give you a heads up that this can lead to confusion. Also for people who want to package this for linux distributions (as I might do soon for Arch Linux). Best regards. |
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, tmuxp and libtmux. With semver, I'd end up having a release number that's like Firefox or Chrome's. Which this thing could adopt. As of yet, I am going by the norms usually seen on python community. It'd look odd as a python project As an example in the poetry package manager, 1.0 to 1.1, 1.1 to 1.2, they break majorly, in django's early releases: https://docs.djangoproject.com/en/dev/internals/deprecation/ deprecations happen between 1.4 to 1.6 for instance, their deprecation policy For the library, I am more conservative with shifting APIs around because its a library and actually throw in deprecation warnings: https://libvcs.git-pull.com/history.html#libvcs-0-4-2020-08-01. But it has very very few users |
@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 this would be needed for this command. |
There isn't a way to do this as of yet. The closest thing would be a test of ours using kaptan.Kaptan.export() to write to a fixture file: vcspull/tests/test_config_file.py Lines 60 to 72 in 1cbaab3
Most of my efforts over the weeks have been "untangling" to make efforts like this easier. |
Hm the "problem" is that For writing this back to file I guess I have to undo the work of |
@Segaja Part of me wishes I never added those If it was just purely the dictionary structure, with the exception of |
I agree. Can we rip it out? :D |
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: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
The text was updated successfully, but these errors were encountered: