search

mesonbuild / mesonwrap

Meson wraps service and tools, please use https://github.com/mesonbuild/wrapdb for wraps issues
https://wrapdb.mesonbuild.com
Apache License 2.0
26 stars 7 forks source link

Feature request: let patches point directly to Git repos #143

Open detly opened 4 years ago

detly commented 4 years ago

I think requiring patches to be tarballs adds an extra intermediate step that's (a) a bit of a burden, and (b) actually more friction than forking a 3rd party repo. For example, say I want to add a Meson config for a 3rd party repo that multiple projects use. Currently my options are...

Option 1: non-VCS-ed config code:

  1. Create a tarball with the meson.build file etc. and upload it somewhere.
  2. Point the wrap file at this tarball.

Downside: the Meson config is code, and not versioning code is asking for trouble.

Option 2: VCS-ed tarball:

  1. Create a new repo, for my meson config additions.
  2. Create a release tarball from this repository.
  3. Point the wrap file at this tarball.

Downsides: I have to create release tarballs repeatedly. I have to get the tarball URL repeatedly.

(*any time I update the Meson config and need the updates in a project.)

Option 3: fork upstream

  1. Fork the 3rd party code into my own repo.
  2. Point the wrap file at this repo.

Downsides: I have to get the commit hash repeatedly (see * above).

IMO option 3 is by far the least work, which is a bit weird to me.

It would be nice if there was an option to point at a patch that is simply a commit in a Git repo ie. eliminate step 2 from option 2 above. Then I neither need a fork, nor to upload tarballs.

Does this seem like a reasonable addition to the wrap system?

detly commented 4 years ago

Quick not from IRC, where eschwartz points out:

for Option 3: fork upstream
you don't need to get the commit hash repeatedly
wrap-git supports using the commit "head"

I'm trying to be fair to existing options — some people (me included) don't want to just track "head", they'll want to be able to test against a new commit before using it, which is arguably an advantage that pointing at unchanging tarballs has.

detly commented 4 years ago

Also raised (paraphrasing): what's wrong with tracking https://github.com/username/repo/archive/<hash>.tar.gz?

Me: that works for github, but is extremely annoying for gitlab (which requires an API call to get the URL I think?), and impossible to generalise to other platforms, whereas just relying on the git protocol itself means there's no question about what URLs the platform supports.