3rd party code?

(1) By Robert Hairgrove (bobhairgrove) on 2023-03-05 19:47:45 [link] [source]

What is the best practice for a project which includes 3rd-party source code to be compiled with the rest of the project, but which seldom (or never) changes? If someone clones the repository, they will obviously need these sources as well as the other things that are changing over time, so I will need to add these files to the repository when it is first set up.

Afterwards, can these be somehow marked as "immutable" by all but the setup admin user? At present, all 3rd party code is in a folder of its own. Should I add this folder to the "ignore-glob" setting? Or will it then be excluded from future clones?

(2) By S. Ross Gohlke (rossgohlke) on 2023-03-05 20:10:29 in reply to 1 [link] [source]

You could put the 3rd party code in as unversioned files and not give anyone else Write Unversioned capability. In this way, contributors can pull the 3rd party code but cannot push back changes to it. And they must pass -u flag to clone command to get it.

The drawback is it has to be handled separately -- the files would need to be exported with fossil uv export before they could be used in a build.

Also, it is not immutable in the sense that it can be removed. As long as you keep a separate copy yourself, it can be easily added back.

(3) By Warren Young (wyoung) on 2023-03-05 20:53:52 in reply to 1 [source]

What is the best practice…

There's no widespread agreement, thus no "best."

Personally, I try to push as much down into the platform level as possible. When my platform won't give me a given library or similar, I write scripts to retrieve as much via third-party package repositories as possible.¹ In the exceedingly rare cases where both of those fail, I will then script a source repo or tarball pull and the commands needed to unpack and build it in place. It is exceedingly rare that I will drop third-party code as-is into a Fossil repo.

If this philosophy is attractive, but you find yourself saying, "Yeah, but…" give us a specific example of third-party code that can't be treated by any of my preferred options above. Without that, we can only give you generalities.

can these be somehow marked as "immutable"

Fossil has no such feature.

One alternative is to put this third-party code into a separate repo, which has a different set of user permissions. Then you can say, "all the developers have clone access to this one, but not commit access."

Or, you can make it a management issue and say, "Don't change code in this subdirectory." If you have people who will not comply with a simple directive like that, do you really want to keep employing them? What other directives will they ignore?

You can try splitting the difference by putting the third-party code on a vendor branch. At least then you've got a clean history of versions imported into your repo, so you can spot those who have changed things against policy by doing a temporary merge of the vendor branch back down; if there are diffs, someone's been naughty.

^{^} All the major ones will give you a way to say, "Install all 20 of the packages named in this file."

(4) By Robert Hairgrove (bobhairgrove) on 2023-03-05 21:18:30 in reply to 1 [link] [source]

Thank you, Ross and Warren.

I'm wondering if I could leverage some kind of parent-child relationship? The parent would consist of only the 3rd-party code, then I would make a child branch (or separate repo?) which contained all the rest. If I understand correctly, the child branch can only pull from the parent, but never push.

(5) By Warren Young (wyoung) on 2023-03-05 21:50:45 in reply to 4 [link] [source]

To speak of "branches" gets you right back to the same "no" answers you've already gotten, because you can't have branches across repositories. Short of exotic cases not worth discussing here, there is only one DAG per repo in Fossil.

There's also only one RBAC per repo, hence only one permission set.

This is why I spoke of multiple repos. That gets you multiple DAGs and multiple RBACs.

(6) By Robert Hairgrove (bobhairgrove) on 2023-03-05 22:17:00 in reply to 5 [link] [source]

In that case, I shall move the 3rd-party source code one level up outside of my current working directory and make a separate repository for it. That way, I can handle the user permissions as you suggested.

The check-out of the repository for the 3rd-party code would see the rest of the project as "extra" files, but that wouldn't matter, I suppose -- I can use the "ignore-glob" setting for that.

(7) By anonymous on 2023-03-05 22:24:00 in reply to 6 [link] [source]

Why not use two sibling repositories in adjacent directories under a parent directory?

That avoids any confusion within each directory - except that a makefile in one must refer to the other when building executables.

(8) By Robert Hairgrove (bobhairgrove) on 2023-03-05 22:29:33 in reply to 6 [link] [source]

And if I put it in a sibling of my top-level directory, that would solve the issue of "extra" files, too. :)

(9) By Warren Young (wyoung) on 2023-03-05 22:36:42 in reply to 6 [link] [source]

Rather than open the third-party code repo atop the one that uses it, I'd recommend either:

Parallel directories, so that the consuming repo looks for its third-party code in ../third-party/lib, ../third-party/include and such. Whatever "bootstrap" or "configure" process you have should check to be sure that this exists and is usable.
Install to well-known directories, then consume the results as normal libraries. This can mean installing to the default prefix (typically /usr/local) or doing something like "./configure --prefix=$HOME" and doing a build-per-user setup, with outputs expected in ~/lib, ~/include, etc.