10 ms·

Here is the most important part to me: "Take care when publishing a crate, because a publish is permanent. The version can never be overwritten, and the code c

by conradk 12y ago

Here is the most important part to me: "Take care when publishing a crate, because a publish is permanent. The version can never be overwritten, and the code cannot be deleted. There is no limit to the number of versions which can be published, however." That. Is. Awesome.

zrail 12y ago
This has been true of CPAN for a long time, and comes as a result of it being a network of FTP mirrors. I don't know when people decided it was a good idea to be able to yank a package (for example, from rubygems). It just complicates the whole setup and makes it less flexible.
- steveklabnik 12y ago
  I can speak to the Rubygems case: you'd be surprised at how often people publish proprietary/private information, and then need to pull it down. It happens often enough to actually be a burden on the Rubygems team (at least, when I used to co-work with one of them) that they left 'yank' in.
  - izietto 12y ago
    I think description should be mandatory
    - baq 12y ago
      homepage, too
  - leoc 12y ago
    Licensing problems or other legal hassles are also foreseeable enough that you'd want to be ready for them.
  - anuragbiyani 12y ago
    > you'd be surprised at how often people publish proprietary/private information, and then need to pull it down. But once published, isn't such information already compromised for all practical purposes ? I can understand the legal reason behind "pulling it down" (using someone else's IP, etc), but practically speaking the private information once published cannot really be "undone" (at best you can make it hard to find, and disassociate from yourself).
    - colordrops 12y ago
      What you are saying makes sense, but you are taking on the entire copyright argument with this logic.
    - codexon 12y ago
      Let's say you accidentally published your name, address, and social security number. If it is only up for 1 hour, the chances that anyone malicious sees it is low. If it is there forever, the chances that someone malicious eventually sees it approaches 100%.
- conradk 12y ago
  That's great ! Definitely a argument in favor of Perl. Being more used to NPM (for Javascript) and knowing that you can (or at least you could) unpublish a package, I'm glad to see that with Rust, I won't have to worry about dependencies disappearing for no reason.
  - ceejayoz 12y ago
    CPAN as an argument in favor of Perl? That's a new one on me...
    - conradk 12y ago
      Isn't CPAN for Perl ? I don't actually know CPAN. All I'm saying is that having a package manager that doesn't allow removing packages is an advantage IMO.
      - ceejayoz 12y ago
        Yes, CPAN is for Perl. I'm just saying I've never heard of a particularly good experience with CPAN. CPAN packages can't really be uninstalled (http://stackoverflow.com/questions/2626449/how-can-i-de-install-a-perl-module-installed-via-cpan http://stackoverflow.com/questions/2626449/how-can-i-de-inst...) and seem to be unnaturally prone to dependency hell.
        dllthomas 12y ago
        I've had particularly good experiences with CPAN. Long enough ago I don't remember the details, and I wasn't doing anything exceptionally complicated, but I remember being favorably impressed and able to get my work done without hiccups.
        jdev30 12y ago
        Same here. Its infrequent that I go to CPAN and I am unable to find a package that will help along. The concern about running the entire test suite on module installation really isnt a problem if you think about. Additionally you are able to force the install if it fails on account of a test.
- serve_yay 12y ago
  Huh, I can think of a lot of reasons to take a package down. Though I agree that "sorry you fucked up, too bad" seems a whole lot easier to implement.
  - idbentley 12y ago
    Can you clarify this? Generally, if you've published a package, it's possible someone has downloaded it. If you take it down, that's going to be strange and unexpected behaviour for those people.
    - ecdavis 12y ago
      If you accidentally published sensitive info in that package you may want to contain the damage.
      - kbenson 12y ago
        Then contact the people that run cargo.io and see if they are sympathetic and what options exist in the circumstances. Setting a sane standard of "no, you can't fuck up everybody that has depended on your public package" is a good thing.
    - baq 12y ago
      same with git rebase on master branches and yet people do that sometimes. there'll always be use cases for deleting a package from anywhere no matter what repo we're talking about.
    - FlyingAvatar 12y ago
      Someone has maliciously posted a package with illegal content. Someone has accidentally posted a package that contains a 2TB file, and now all mirrors have to sync it. Someone accidentally puts their personal information in a package.
      - darklajid 12y ago
        Illegal: There are legal ways to make that initial statement ("Cannot be deleted") false. If you're uploading a crate that offers nude pictures of random celebrities the guys at cargo.io will find a way to make this go away. 2TB file: That's .. nonsense. I assume guards are in place to prevent the oldest form of DOS attacks. If not, the guys at cargo.io will learn and .. make that go away? Personal information: That looks like the only case where I sympathize with the guy uploading stuff. That said, this is how the net works? Publishing sensitive stuff to Github means that it might be out there forever (force pushing a new history doesn't mean that no one cloned the stuff before or just grabbed a zip of the current head). For me its a win. I certainly can imagine some scenarios that might be painful, but .. that usually boils down to your third example, a developer error. The usual issue with 'removing packages' is that the user suffers. My gut feeling is that there are far more users that get 404s than developers that share their API keys.
- pauljz 12y ago
  For what it's worth this is also true of NuGet: "NuGet.org does not support permanent deletion of packages, because that would break anyone who is depending on it remaining available. This is particularly true when using the workflow that restores packages on build. Instead, NuGet.org supports a way to 'unlist' a package, which can be done in the package management page on the web site. When a package is unlisted, it no longer shows up in search and in any package listing, both on NuGet.org and from the NuGet Visual Studio extension (or nuget.exe). However, it remains downloadable by specifying its exact version, which is what allows the Restore workflow to continue working. If you run into an exceptional situation where you think one of your packages must be deleted, this can be handled manually by the NuGet team. e.g. if there is a copyright infringement issue, or potentially harmful content, that could be a valid reason to delete it." (Source: http://docs.nuget.org/docs/Creating-Packages/Creating-and-Publishing-a-Package#Deleting_packages http://docs.nuget.org/docs/Creating-Packages/Creating-and-Pu...)
Jabbles 12y ago
I would like to contrast the underlying philosophy here to that of Go. As you may be aware, there is limited support for versioning APIs using "go get" (Go's nearest equivalent of this). The developers of Go argue that the maintenance of your dependencies is your responsibility, and you should clone everything you need to your own environment. That gives you ultimate control, allowing you to pull and update them as you require, modify and bugfix as you see fit, and makes it hard, if not impossible, to end up relying on two packages with different versions. If a project B depends on project A, then they must collaborate in some way to make sure that there are no breaking changes introduced between (minor) versions. If another project C also depends on A, then they must both use the same version of A if they are to be used together. The maintainers of A, B and C all have a duty to ensure that their code remains up-to-date and backwards compatible. It seems that Rust values a different freedom. By specifying the exact version you require, there is no need to keep separate projects in sync. The flexibility comes at a cost; you may find you have different versions of many dependencies. Because they are not required to, maintainers may neglect the tedious task of keeping their projects' dependencies up-to-date, requiring bugfixes in multiple places in your own codebase. Clearly, some of the smartest minds in our industry disagree what the best tradeoff is. It is interesting to see the range of opinion though.
- steveklabnik 12y ago
  Small nits about the way this works: > By specifying the exact version you require, This is only half true. It comes in two steps: you specify a _kind_ of version that you require, like foo = "^1.2.0" and then, during the build step, it resolves all of the dependencies and their dependencies (etc) and writes the exact version out to a file. So you do end up with specific ones, but you won't neccesarily end up with multiple versions. This also matters because... > maintainers may neglect the tedious task of keeping their projects' dependencies up-to-date, You just run 'cargo update' and it will re-calculate that dependency graph, and re-write out the lock file. You're as up to date as you can be. Of course, if that fix is only available in a range outside you've specified, that's different.
- andrewchambers 12y ago
  Go is always statically linked at the moment so it makes more sense in that scenario.
pjc50 12y ago
the code cannot be deleted Well, that's a problem waiting to happen. Infringing source? Malicious material? It's a publishing facility and so will be abused.
- whyever 12y ago
  Exceptions can be treated exceptionally. No need to allow deleting as part of everyday usage.

by conradk 12y ago

zrail 12y ago

This has been true of CPAN for a long time, and comes as a result of it being a network of FTP mirrors. I don't know when people decided it was a good idea to be able to yank a package (for example, from rubygems). It just complicates the whole setup and makes it less flexible.

steveklabnik 12y ago
I can speak to the Rubygems case: you'd be surprised at how often people publish proprietary/private information, and then need to pull it down. It happens often enough to actually be a burden on the Rubygems team (at least, when I used to co-work with one of them) that they left 'yank' in.
- izietto 12y ago
  I think description should be mandatory
  - baq 12y ago
    homepage, too
- leoc 12y ago
  Licensing problems or other legal hassles are also foreseeable enough that you'd want to be ready for them.
- anuragbiyani 12y ago
  > you'd be surprised at how often people publish proprietary/private information, and then need to pull it down. But once published, isn't such information already compromised for all practical purposes ? I can understand the legal reason behind "pulling it down" (using someone else's IP, etc), but practically speaking the private information once published cannot really be "undone" (at best you can make it hard to find, and disassociate from yourself).
  - colordrops 12y ago
    What you are saying makes sense, but you are taking on the entire copyright argument with this logic.
  - codexon 12y ago
    Let's say you accidentally published your name, address, and social security number. If it is only up for 1 hour, the chances that anyone malicious sees it is low. If it is there forever, the chances that someone malicious eventually sees it approaches 100%.
conradk 12y ago
That's great ! Definitely a argument in favor of Perl. Being more used to NPM (for Javascript) and knowing that you can (or at least you could) unpublish a package, I'm glad to see that with Rust, I won't have to worry about dependencies disappearing for no reason.
- ceejayoz 12y ago
  CPAN as an argument in favor of Perl? That's a new one on me...
  - conradk 12y ago
    Isn't CPAN for Perl ? I don't actually know CPAN. All I'm saying is that having a package manager that doesn't allow removing packages is an advantage IMO.
    - ceejayoz 12y ago
      Yes, CPAN is for Perl. I'm just saying I've never heard of a particularly good experience with CPAN. CPAN packages can't really be uninstalled (http://stackoverflow.com/questions/2626449/how-can-i-de-install-a-perl-module-installed-via-cpan http://stackoverflow.com/questions/2626449/how-can-i-de-inst...) and seem to be unnaturally prone to dependency hell.
      - dllthomas 12y ago
        I've had particularly good experiences with CPAN. Long enough ago I don't remember the details, and I wasn't doing anything exceptionally complicated, but I remember being favorably impressed and able to get my work done without hiccups.
        jdev30 12y ago
        Same here. Its infrequent that I go to CPAN and I am unable to find a package that will help along. The concern about running the entire test suite on module installation really isnt a problem if you think about. Additionally you are able to force the install if it fails on account of a test.
serve_yay 12y ago
Huh, I can think of a lot of reasons to take a package down. Though I agree that "sorry you fucked up, too bad" seems a whole lot easier to implement.
- idbentley 12y ago
  Can you clarify this? Generally, if you've published a package, it's possible someone has downloaded it. If you take it down, that's going to be strange and unexpected behaviour for those people.
  - ecdavis 12y ago
    If you accidentally published sensitive info in that package you may want to contain the damage.
    - kbenson 12y ago
      Then contact the people that run cargo.io and see if they are sympathetic and what options exist in the circumstances. Setting a sane standard of "no, you can't fuck up everybody that has depended on your public package" is a good thing.
  - baq 12y ago
    same with git rebase on master branches and yet people do that sometimes. there'll always be use cases for deleting a package from anywhere no matter what repo we're talking about.
  - FlyingAvatar 12y ago
    Someone has maliciously posted a package with illegal content. Someone has accidentally posted a package that contains a 2TB file, and now all mirrors have to sync it. Someone accidentally puts their personal information in a package.
    - darklajid 12y ago
      Illegal: There are legal ways to make that initial statement ("Cannot be deleted") false. If you're uploading a crate that offers nude pictures of random celebrities the guys at cargo.io will find a way to make this go away. 2TB file: That's .. nonsense. I assume guards are in place to prevent the oldest form of DOS attacks. If not, the guys at cargo.io will learn and .. make that go away? Personal information: That looks like the only case where I sympathize with the guy uploading stuff. That said, this is how the net works? Publishing sensitive stuff to Github means that it might be out there forever (force pushing a new history doesn't mean that no one cloned the stuff before or just grabbed a zip of the current head). For me its a win. I certainly can imagine some scenarios that might be painful, but .. that usually boils down to your third example, a developer error. The usual issue with 'removing packages' is that the user suffers. My gut feeling is that there are far more users that get 404s than developers that share their API keys.
pauljz 12y ago
For what it's worth this is also true of NuGet: "NuGet.org does not support permanent deletion of packages, because that would break anyone who is depending on it remaining available. This is particularly true when using the workflow that restores packages on build. Instead, NuGet.org supports a way to 'unlist' a package, which can be done in the package management page on the web site. When a package is unlisted, it no longer shows up in search and in any package listing, both on NuGet.org and from the NuGet Visual Studio extension (or nuget.exe). However, it remains downloadable by specifying its exact version, which is what allows the Restore workflow to continue working. If you run into an exceptional situation where you think one of your packages must be deleted, this can be handled manually by the NuGet team. e.g. if there is a copyright infringement issue, or potentially harmful content, that could be a valid reason to delete it." (Source: http://docs.nuget.org/docs/Creating-Packages/Creating-and-Publishing-a-Package#Deleting_packages http://docs.nuget.org/docs/Creating-Packages/Creating-and-Pu...)

Jabbles 12y ago

I would like to contrast the underlying philosophy here to that of Go. As you may be aware, there is limited support for versioning APIs using "go get" (Go's nearest equivalent of this). The developers of Go argue that the maintenance of your dependencies is your responsibility, and you should clone everything you need to your own environment. That gives you ultimate control, allowing you to pull and update them as you require, modify and bugfix as you see fit, and makes it hard, if not impossible, to end up relying on two packages with different versions. If a project B depends on project A, then they must collaborate in some way to make sure that there are no breaking changes introduced between (minor) versions. If another project C also depends on A, then they must both use the same version of A if they are to be used together. The maintainers of A, B and C all have a duty to ensure that their code remains up-to-date and backwards compatible. It seems that Rust values a different freedom. By specifying the exact version you require, there is no need to keep separate projects in sync. The flexibility comes at a cost; you may find you have different versions of many dependencies. Because they are not required to, maintainers may neglect the tedious task of keeping their projects' dependencies up-to-date, requiring bugfixes in multiple places in your own codebase. Clearly, some of the smartest minds in our industry disagree what the best tradeoff is. It is interesting to see the range of opinion though.

steveklabnik 12y ago
Small nits about the way this works: > By specifying the exact version you require, This is only half true. It comes in two steps: you specify a _kind_ of version that you require, like foo = "^1.2.0" and then, during the build step, it resolves all of the dependencies and their dependencies (etc) and writes the exact version out to a file. So you do end up with specific ones, but you won't neccesarily end up with multiple versions. This also matters because... > maintainers may neglect the tedious task of keeping their projects' dependencies up-to-date, You just run 'cargo update' and it will re-calculate that dependency graph, and re-write out the lock file. You're as up to date as you can be. Of course, if that fix is only available in a range outside you've specified, that's different.
andrewchambers 12y ago
Go is always statically linked at the moment so it makes more sense in that scenario.

pjc50 12y ago

the code cannot be deleted Well, that's a problem waiting to happen. Infringing source? Malicious material? It's a publishing facility and so will be abused.

whyever 12y ago
Exceptions can be treated exceptionally. No need to allow deleting as part of everyday usage.