Is there a way to download a file that doesn't end with .crate extension?

[dpc]

I need an ability to let people download a crate and easily open it for viewing.

Right now /download endpoint returns something that confuses all the tools because it has .crate extension, even though the file itself is some standard archive.

[carols10cents]

I don't know of a way. Cargo would be confused if the files didn't. The .crate files are .tar archives.

[dpc]

If the file ended with .crate.tarthen the desktop clients wouldn't get confused and user able to browse files directly.

Do you think it's possible to add an argument for the format of the filename?

[carols10cents]

What desktop clients are you referring to?

[dpc]

I'm following https://crates.io/api/v1/crates/adler32/1.0.2/download in Firefox on my Fedora 26 with Gnome Shell. I'm not sure if it's a local problem, but the default archive extractor gets confused and fails to open .crate file there.

[sgrif]

Perhaps we should better document that the files are just tar archives, but it doesn't seem like that big of a hassle to rename the file if you're wanting to use GUI tools/tools that infer what to do from the file name. tar definitely works fine with them.

[dpc]

Hmmm... Maybe I should have explained better. If you think about these endpoints to be consumed by software then it doesn't really matter at all.

However, I'm planning to embed /download links on my own website so that users can easily download/view the source code of packages inside a browser. I'd like the user to click a link, get an archive opened and then be able to browse and open source files inside. Any problems with it are making the user's experience worse. That's why I'm looking for the most standard, and natural way to achieve it.

[sgrif]

Given that most users aren't on operating systems that can open tar archives by default, I think you'll need to do some additional processing on your end to make that work.

[dpc]

I would expect most Rust users to be on Linux/Mac. I'm Linux user myself, so I know it would work on Linux. I'm not sure about Mac, but I hope it would work as well.

Maybe crate.io should itself provide a zip file download. I mean... shouldn't we expose an easy to use link so that users that want to, can easily verify that what they are planning to use, is not completely different from what is advertised in "Repository" link?

[dpc]

The real-life example, since I've deployed my code already: https://hackeraudit.com/package/crates.io/adler32/1.0.2

[jtgeibel]

@dpc I'm not sure I see any practical way we can change this. It could be possible to use Content-Disposition: attachment; filename="name.tar.gz" to provide a specific filename to the browser, but given that our download route is just a redirect to S3 I'm not sure this would actually work.

I'm on Linux in a KDE environment and the link on your site works fine for me. Firefox identifies it as a "Tar archive" and offers the ability to open it in the default program (Ark). If I download the file then the KDE file explorer (Dolphin) identifies it as a "Gzip archive". It appears that the Firefox UI is based on the content type headers, but the local file explorer is presumably doing content sniffing. In both cases, it is correctly opening on my system.

Part of the confusion may be that we (via S3) provide a content-type: application/x-tar header while the file is actually a gziped tar. If tar was a registered MIME type, then it looks like application/tar+gzip would be the best option, but there is no official tar MIME type. Wikipedia seems to suggest application/x-gtar as an option, but I have no idea if clients would handle that correctly either.

We actually used to have a download button directly on crates.io, but this was removed some time ago in #15 as "there's not much you can do with it anyway." I don't expect that crates.io will ever offer zip files for download, so there are still the cross platform issues as well.

Maybe the best solution would be to offer some kind of cargo download command that would download, verify the hash against the registry index, and then extract the files. This would have the added benefits of being cross platform and verifying the integrity of the download.

[dpc]

@jtgeibel Thanks for all the information.

I really like the idea of cargo download. It would help to view and manually verify the source of dependencies. Maybe there is already something kind of like that?

Maybe we could also have an URL that could be associated with cargo tool. crates.io://adler32/1.0.2 or something like that :)

[steveklabnik]

it's called `cargo-clone`

…

On Wed, Jan 10, 2018 at 7:58 PM, Dawid Ciężarkiewicz < ***@***.***> wrote: @jtgeibel <https://github.com/jtgeibel> Thanks for all the information. I really like the idea of cargo download. It would help to view and manually verify the source of dependencies. Maybe there is already something kind of like that? Maybe we could also have an URL that could be associated with cargo tool. crates.io://adler32/1.0.2 or something like that :) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1219 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABsim3iR20CyACFlpym83tJ-bK4diyGks5tJVzDgaJpZM4RVGhH> .

[jtgeibel]

Looks good to me. I'm going to go ahead and close this as I think this functionality is best supported in a cross-platform way by the suggested cargo-clone crate.