search

cunarist / rinf

Rust for native business logic, Flutter for flexible and beautiful GUI
MIT License
1.99k stars 72 forks source link

Pull latest cargokit and add script #166

Closed bookshiyi closed 1 year ago

bookshiyi commented 1 year ago

How do you think that integrate update cargokit script to CI program

temeddix commented 1 year ago

Actually, those are intended to be done with automate/__main__.py file, so that we can use python automate bridge-gen or other commands. What do you think about writing the automation script of integrating newest cargokit in that file? I think that Python file's content would be easy for a talented coder like you to understand :)

Maybe we can have a new command python automate cargokit-update.

bookshiyi commented 1 year ago

Actually, those are intended to be done with automate/__main__.py file, so that we can use python automate bridge-gen or other commands. What do you think about writing the automation script of integrating newest cargokit in that file? I think that Python file's content would be easy for a talented coder like you to understand :)

Maybe we can have a new command python automate cargokit-update.

yeah! It's a great idea to put automated scripts together.

But I still doubt whether it is necessary for python to implement scripts. After all, it makes the runing environment a little more demanding than bash scripts.

Is there any special reason to choose python?

temeddix commented 1 year ago

Yeah, for mainly two reasons:

There are some repositories using shell commands, but I saw many of those becoming a barrier between users between platforms 😂

temeddix commented 1 year ago

Great :) does this work as expected, updating cargokit with some # Different from upstreams on your machine?

bookshiyi commented 1 year ago

Yeah, for mainly two reasons:

  • We can write once, use it on all windows, macos and Linux. bat or sh files are not qualified for that. This is very CI-friendly.
  • It's easy to manipulate strings, numbers with methods and regex. Manipulating files can also be done in a platform-agnostic way.

There are some repositories using shell commands, but I saw many of those becoming a barrier between users between platforms 😂

Thank you for your patient reply. I understand your idea. I did ignore the script running problem of the non-*nix platform. Python is indeed an excellent os-independent script actuator.

temeddix commented 1 year ago

I'm happy that we have a consensus, thank you for respecting this :D

bookshiyi commented 1 year ago

Great :) does this work as expected, updating cargokit with some #Different from upstream on your machine?

In my experience, the command git subtree pull won't change the code which commented with #Different from upstream.

temeddix commented 1 year ago

Oh, that's very interesting. Then I think this system does make a lot of sense 👍

bookshiyi commented 1 year ago

Is it possible to integrate the automation scripts that RIF maintainers and RIF users will use?

RIF maintainers: bridge-gen, cargokit-update RIF users: message, wasm, template

(RIF uses both dart, rust and python scripts now 😂)

temeddix commented 1 year ago

Good morning :)

There are reasons why scripts for 'US' have been splitted from scripts for 'USERS'. If you take a look at .pubignore file, you can see that some files and folders are excluded from being published to pub.dev, and that our ./automate folder is one of them. This was because I thought scripts for 'US' should never be exposed to the RIF 'USERS', since these are just related to the maintenance of this framework and has nothing to do with developing the app.

Of course, we could write the script in ./bin folder as dart files, but then those scripts only for 'US' will be published to RIF 'USERS' which would be not ideal. That's why I thought using a totally separate, but universal language would be ideal for maintaining this repository, which was Python.

bookshiyi commented 1 year ago

Good morning :)

There are reasons why scripts for 'US' have been splitted from scripts for 'USERS'. If you take a look at .pubignore file, you can see that some files and folders are excluded from being published to pub.dev, and that our ./automate folder is one of them. This was because I thought scripts for 'US' should never be exposed to the RIF 'USERS', since these are just related to the maintenance of this framework and has nothing to do with developing the app.

Of course, we could write the script in ./bin folder as dart files, but then those scripts only for 'US' will be published to RIF 'USERS' which would be not ideal. That's why I thought using a totally separate, but universal language would be ideal for maintaining this repository, which was Python.

Thanks for your detailed introduction, my understanding is deeper.

It is necessary to separate maintainers and users scripts. It is also necessary for multiple scripts to use the same language.