-
Notifications
You must be signed in to change notification settings - Fork 1
Rename vset commands respectively to config-list, config-set, config-get commands #2
Comments
In fact, because Brush is based on drush 4.x there is already |
Is it only a rename (or API only change)? [I have time for that] Or is it a complete code re-write? [Don't have time for this though :( ] I had to fix one of my alias that used Drupal variables (Backdrop configs) and it entailed a code change as B-configs are now flat files and not in the DB like D-variables. Best, |
The https://api.backdropcms.org/api/backdrop/core%21includes%21config.inc/function/config_get/1 instead. |
Thanks Alan, Working on it. It seems like more than just Ref:
|
Hi Michael, If you gonna work on this please make sure to git clone the latest dev branch as I am constantly pushing various fixes. |
You won't find that many occurrences on development branch. Please see e8cb73e |
Okay, Cloned the dev branch to work with. * I am amused by the addition of state_get, which pretty much invalidates the rational for converting variable_get to config_get? This issue also seems dependent on: backdrop/backdrop-issues#1954 While this is convertible:
I’d very much like to not remove the aliases to ‘vget’ (vset, ...) so the above is convertible by just changing Granted I’m not sure how to work that with In any event forcing a user to know what the JSON file name is for some variable they need to look up is fairly counterproductive. It’d suck though to have to use a disk scan, although for a temporary measure it’d be okay I guess. I’ll look into it more tomorrow. Best,
PS: /brush-1.x-1.3/commands/core/upgrade.brush.inc I agree it’s not a Backdrop ‘thing’ anymore but it does show why it’s coded the way it’s coded. Painless to leave it in and will curtail having to explain it in the future. |
Thanks for your comments. I'll definitely take them all into my attention. For instance, you've changed my mind about leaving the original comments. Because, before I believed that eventually the code could be totally polished, cleaned up and left with only Backdrop related code, including the terminology and the lingua of the comments.
If I am not mistaken, the Backdrop consensus decided to differentiate between
and
I agree. Let's change only
Unfortunately, we at AltaGrade are busy with lot's of our own - mostly system administration, bus sometimes Backdrop - tasks. Only when we hit the point we need certain feature from You wanna become co-maintainer? You are really welcome to join in and improving the code. I really though b is the right way to go. However, if someone is using this tool and wants to further support it, then I'll be only thankful and try to be helpful.
You could ask on https://backdrop.zulipchat.com and I am pretty sure everyone will be helpful. I think we could add a new feature to
Which one, I now wonder? |
Hi Alan, I already did a wall of text today, so I’ll try to keep this short :(
Fully understand that, business owner myself! Time spent on projects like this are time not spent on something billable. :(
I don’t mind. Do understand I don’t know git (granted I can read docs), so I’d much rather do PRs like the last one so someone who actually knows git can at least review what I’ve changed.
That’s a third Drush clone? The only other one I knew about was ??? which gave instructions using Lando to install it. Ah, ‘b’ as the executable name? Not really a good sign. I’m still going to try it, I need to update a dev Backdrop/CiviCRM site. But based on the replies I’m getting in the other thread, it’s not going to do vget the way I want, so I’ll be sticking with brush for the long term.
Agree with both of these. I use drush 5.x on all my production servers running D7 because I never needed any of the later ‘stuff’ and why waste the time (and wondering about potential bugs) up-reving drush? My goals are:
As far as I’ve tested, brush does everything else I want.
The git clone for pulling the HEAD. New software, and this applies to about any software, the simplest things are just ‘known.’ Probably like the auto re-versioning, I found references that it could be done, but no real concrete methods... Okay, got to go, busy for the rest of the day, you be well. Best, |
I totally forgot that unlike drupal.org (where we could add co-maintainers any time by ourselves), all the Backdrop projects here belong to https://github.com/backdrop-contrib, and you have to pass through a procedure in order to become a co-maintainer. Please read https://backdropcms.org/contribute/join for the detailed information. If you feel it's too early for you then you can keep contributing just making PRs.
Please read README.md on https://github.com/backdrop-contrib/brush to see the differences between consoles.
That kind of differences were one of the reasons to come up with brush without bothering developers of other two consoles.
Well,
Now I see. HEAD will have all the changes that we've pushed recently, so if you are a developer then it's better to have fresher code. But then you don't have to run
Don't worry about it as it's fixed on dev branch. In other words, |
This has partially been fixed. Please see #12 |
|
This has finally been fixed. Here are outputs for four newly introduced commands:
|
Subj.
The text was updated successfully, but these errors were encountered: