cargo-aur

cargo-aur copied to clipboard

Hi, I've been using and following the project for a while now, I think it's great and I really appreciate the existence of this project.

As a developer I have been wanting to contribute to certain things that I would like to have in the official version, here is a list of the things I am including with this pr

Features:

• Customizable output path
• Replacement of gumdrop by clap
• Subcommands for build and generate
• Generation of the PKGBUILD with a previously generated tar
• New parameters added to the aur metadata
  • package_name: to make the package name more customizable using template strings, more info here
  • source_download: for those who want to have another provider apart from github and gitlab, here also use template string to make it more customizable
• Restructuring of the project into modules to facilitate development.

Fixes:

• All files arrive to custom output path.
• Better error handling (Implementing a trait to have ExitCode linked to Result)
• More understandable commands (There is a possibility to generate usage but I listen to opinions)

Things I plan to add in another PR:

• That the build architecture is customizable through the arguments, this is because ArchLinux has a version arm and could be published for both without problem.
• log crate with env_logger for trace errors or debug

cargo aur -h

cargo aur -o out generate ./target/cargo-aur/cargo-aur-1.6.0-x86_64.tar.gz

cargo aur -o out build

Thank you very much for these contributions! While it may be a bit more work, could you split each proposed feature / improvement into a different PR? That way I can review them separately.

Here are my immediate thoughts:

Customizable output path

This is a good idea and should be added.

Replacement of gumdrop by clap

The choice of gumdrop here is on purpose to keep the binary small. clap is quite a large dependency (which I happily use elsewhere, but not here).

Subcommands for build and generate

Adding these would actually break the user-facing API. The current usage is cargo aur and this should be respected to maintain user happiness.

Generation of the PKGBUILD with a previously generated tar

Can you elaborate on what this is?

New parameters added to the aur metadata

These are reasonable and can be added separately.

Thank you very much for these contributions! While it may be a bit more work, could you split each proposed feature / improvement into a different PR? That way I can review them separately.

Originally I was doing it this way, but it happens that wanting to modularize it would break the rest of the integrations I wanted to do or otherwise it would take much longer to do the PR's, but let me know if you prefer it this way and I'll see if I can put together multiple PR's.

The choice of gumdrop here is on purpose to keep the binary small. clap is quite a large dependency (which I happily use elsewhere, but not here).

With all the libraries I added, including clap and srtemplate the weight is not abysmally different, so I think there is not much to worry about. Currently with a compilation using rust 1.73-stable compiling for linux gnu it has a weight of 994k with respect to the weight of the master branch, using the same version of rust and compiling for linux gnu it weighs 674k as well. I'm not sure if gumpdrop supports subcommands like clap does, but I could see it.

Adding these would actually break the user-facing API. The current usage is cargo aur and this should be respected to maintain user happiness.

Yep, that's what I was thinking, it could break the current operation, but it seems to me that the library is able to have a change in this way and it would even be beneficial because it can establish in a more organized way the separation of processes to be executed, separating the generation of the build, for example, and if later you want to add a check, it can be very useful. Similarly, the operation remains the same, the only change is that the --musl flag becomes a parameter of the subcommand build, the rest of the command is respected, it remains cargo aur ...

Can you elaborate on what this is?

Of course, sometimes you need to do a different or more customized packaging, for these cases it is not cargo-aur who does it, so we added the process of generating a PKGBUILD file using an existing tar.gz file, this for example is very useful for CI/CD processes cargo-aur is just another step that does not break the rest of the steps. NOTE: ideally in the future it would be good to use some tar management library.

Hey sorry for the inconvenience, I stopped by to ask if you had time to review anything or would you prefer me to do the PR's individually so I can start separating out the changes

Forgive me for my late response. Could we move forward with separate PRs for:

• Customizable output path
• New parameters added to the aur metadata

We can discuss the other features after that. Thank you kindly!

I would also like to be able to separate it into modules because the code will grow much more and it can become complicated to collaborate and maintain it, but now I prepare the PR's

The PR was very large and was not accepted, it is closed in order to open new PR's