[Feature] Single-dependency file

[goddaneel]

While using wrap-file, I noticed that it forcefully extracts downloaded files. I sort of understand that this feature was originally designed for subprojects.

However, sometimes I need to download a single, uncompressed file from the web as a project dependency—for example, an icon. Therefore, the current wrap functionality doesn’t meet my needs.

So I was wondering if it would be possible to design a wrap type specifically for single files, or to set up a separate system dedicated to downloading single-file dependencies without extracting or performing any other processing.

I realize this may conflict with the design philosophy behind subprojects, but I believe this is a common need, so I hope to see this feature implemented in Meson. Thank you very much.

[eli-schwartz]

While using wrap-file, I noticed that it forcefully extracts downloaded files. I sort of understand that this feature was originally designed for subprojects.

wrap-file is a subtype of the subprojects/ directory. The relationship here is stronger than the word "originally" implies.

However, sometimes I need to download a single, uncompressed file from the web as a project dependency—for example, an icon. Therefore, the current wrap functionality doesn’t meet my needs.

This doesn't sound like a dependency -- it sounds like a core project asset. When would you ever not want to have it as part of your project sources -- i.e. checked into git? If it is about file size, you need the file to build so you would want the file in meson dist tarballs, but if you didn't want it to bloat the size of the git repository then that sounds like an argument in favor of using Git LFS. Which would still be part of the repository itself, no?

[goddaneel]

I hope to implement this functionality using wrap, since wrap already has the capability to download and verify individual files—it just needs to skip the extraction step, which shouldn’t be too difficult.

Just as Meson avoids performing operations in the repository’s source directory, I don’t believe certain files should be included in my Git commit history. As for some large files, Git LFS doesn’t change the fact that the repository itself is massive—it merely handles the two separately. Moreover, LFS still consumes my cloud storage space, even though I only need to download the files from the source, such as an ISO file that’s several hundred megabytes in size.

Furthermore, sometimes I want to handle certain archive files myself—such as non-standard packages like deb or rpm. These aren’t necessarily subprojects, but I do need to extract content from them. And even for subprojects, I might not need all the files—perhaps just one.

Finally, perhaps the simplest reason: I think it’s far too much trouble to create a repository just for a single file, or to download it, compress it into an archive, and then upload it somewhere.

Therefore, I would be extremely grateful if this could be implemented. Of course, this is just a personal need; if you feel it conflicts with your design philosophy, I certainly shouldn’t ask you to do anything.

[thesamesam]

I think you want to implement this as a dependency where you have some script that runs as a regular target which then runs wget or what-have-you.

If we were to implement support for this, it definitely wouldn't be via the wrap machinery, but I don't see us adding generic download helpers into Meson in any case.

Also, where would it end? Off the top of my head, people may want custom checksums, PGP verification (or worse methods of cryptographic validation), they may want custom fetch methods we can't support, resume support, who knows what else? We're then in the business of maintaining curl-lite, or depending on curl (or a similar library) which we don't want to do.

believe this is a common need,

This is the first time I've heard of anyone asking for it.

[goddaneel]

What I mean is, I don't need to turn Meson into a general-purpose downloader. Because I already have other specialized, feature-rich download tools, I don’t think I need to introduce a complex, general-purpose download tool into Meson.

I simply noticed that wrap-file already has the capability to download any file—you just need to skip the extraction step. In fact, all I need is for Meson to be able to download a single file and verify it using a hash. It’s that simple—no GPG verification, no resume support, and not even retry on failure. And these are all features that wrap-file already supports.

You don’t need to explain to me again that wrap is used for modules or subprojects—I know that. I’m simply pointing out that this feature also supports downloading single files; you just need to skip the extraction step after downloading—that’s all.

As for your concern that implementing this feature might eventually turn it into a general-purpose downloader, I believe that’s an unfounded speculation. After all, Meson already supports downloading single files; it’s just that an extraction step has been forcibly added. If adding a download feature were to lead to increased complexity, then shouldn’t wrap-file not exist at all?

As mentioned above, it is precisely because I do not want to introduce a full-featured, general-purpose downloader into Meson that I am suggesting we trim the functionality of wrap-file to support single-file dependencies. Download, verify, and pass the path—that’s all.

(Since English is not my native language, I need to rely on translation tools. Please forgive me if there are any inaccuracies in my wording; I mean no harm.)

[thesamesam]

What I mean is, I don't need to turn Meson into a general-purpose downloader. Because I already have other specialized, feature-rich download tools, I don’t think I need to introduce a complex, general-purpose download tool into Meson.

You don't, but someone may well ask for these once we let Meson do this.

You don’t need to explain to me again that wrap is used for modules or subprojects—I know that. I’m simply pointing out that this feature also supports downloading single files; you just need to skip the extraction step after downloading—that’s all.

I don't know what you do or don't know, but it generally helps to be detailed so my reasoning is clear for others.

If adding a download feature were to lead to increased complexity, then shouldn’t wrap-file not exist at all?

A single file cannot be a project by itself (no build system or the like). An archive however can produce one.