Repo refactor (keep it simple and separate concerns) about proot-static-build

[jopasserat]

Hey @fsquillace, thanks for the feedback!
Here're my (late but hopefully thorough) opinions:

Moving CARE to a different project

Yes it would be a good idea but I have absolutely no idea how that would impact the development.
What will have to be imported and how? Typically the header files? It's not like in Java where you have all the artefacts repos which you can draw jars from.

Do you have any design idea suggesting what it would look like?

Repo size

Definitely agree!
When I have time:

• I'll remove the binaries and keep only the library dependencies.
• I'll migrate the repo to git LFS

Dynamically points to different PRoot code

Can you expand a bit on that one?
And potentially submit a PR for what you think would be a good way of doing it?

Solution

Happy to merge parts of your Makefile in this one if it improves on the previous point.
PR is the way ❤️

Vagrant vs Docker

We need Docker...

I disagree that Vagrant suits builds better than Docker, since Docker is fairly well integrated with CIs.

I've recently noticed (shame on me) the cross-build-env folder in the PRoot source tree. I believe it contains scripts to cross-build PRoot for different architectures.

I don't have any expertise with that myself but would be great to investigate this solution or reuse parts of it.

Also, maybe these scripts should be moved here?

... but we also need Vagrant

But Vagrant would help new contributors getting started with PRoot development so please PR a nice Vagrantfile!!

I think both the Vagrantfile(s) and Dockerfile(s) should stay in the repo as they:

• are an inherent part of the development cycle
• don't harm the size
• can be hidden in a subfolder if you don't want them as top folder elements

Communication

We've opened a gitter channel for development related discussions: https://gitter.im/proot-me/devs

You should be able to join but if not ping me :)

Gitter is probably better than issues for long discussions (and it's now Free and Open Source 😄)

[fsquillace]

Dynamically points to different PRoot code

I was thinking something like the solution I proposed.
Namely, as such repo contains the way proot needs to be built, such repo should have the ability to choose which source take into account. For instance, via proot-url variable you can define what is the source to consider:

make proot proot-url=https://github.com/myuser/PRoot.git proot-branch=myproot

Vagrant vs Docker

I agree with you about the fact that even docker can be a good choice. In fact, there is no so much support for vagrant in CIs (which is an issue I have struggled with). I believe that both Docker and Vagrant are useful indeed. For my project I do need to use Vagrant only as it allows me to build proot for different architectures. My proposal is to separate building part with the provider used into two different repositories, as they are, IMHO, two separate concerns. For instance I use proot-vagrant which takes the proot-static build and provisions a machine using any provider via Vagrant. If someone else wants to use a different approach (neither Docker nor Vagrant) they can still use the basic proot-statci build code.

Moving CARE to a different project

As I have not seen any benefits of having CARE into the proot makefile I have removed any target (and its related dependecies) to obtain something like this.

Communication

Yes, I will communicate with gitter for further issues in the future. For this specific issue we may want to keep in the github issues for a bit more visibility.

[oxr463]

On Moving Care...

Also, CARE is a completely different project and, IMHO it should be placed in a different repo in order to facilitate the maintenance of it.

Yes it would be a good idea but I have absolutely no idea how that would impact the development.

Moving CARE seems unnecessary since both applications utilize the same source tree. There are many projects that contain multiple tools in one repository since they share code so I don't think we should worry about this unless they somehow diverge.

Static Releases

Static binaries can and should be released along with source code distributions via GitHub releases from the main repository. That requires a bit more work with our current continuous integration pipeline, but eventually this repository should be deleted, (or at least archived and/or all binary files removed).

Docker vs Vagrant - Why not both?

Feel free to submit a Vagrant file if you'd like, but Docker is vital for continuous integration;
being able to recreate the exact same environment locally as if it were running on travis (or circle-ci, gitlab, etc.), is invaluable and can save development time when troubleshooting.