Skip to content
This repository has been archived by the owner on Jul 4, 2023. It is now read-only.

Proposal: add cargo to rust formula #33322

Closed
RSully opened this issue Oct 18, 2014 · 18 comments
Closed

Proposal: add cargo to rust formula #33322

RSully opened this issue Oct 18, 2014 · 18 comments

Comments

@RSully
Copy link

RSully commented Oct 18, 2014

I'm not sure if homebrew would prefer this as a separate formula or --with-cargo as an option within the rust formula.

For comparison:

  • homebrew-php separates composer into its own formula
  • node installs npm by default

My vote goes to installing cargo by default within the rust formula.

@DomT4
Copy link
Member

DomT4 commented Oct 18, 2014

I'd be 👍 on this but at last check Cargo wasn't stable yet? Or at least doesn't have a stable release?

Having to clone the git and then build Cargo from source manually is a bit of an additional pain, especially when we could be cloning slightly different Cargo sources into Rust on a day to day basis. Cargo also has 4 major dependencies that Rust doesn't.

The upside of npm inside Node is that it has stable releases, and doesn't force any additional dependencies. (Largely because Node ships those dependencies, which isn't trouble-free either, but eh).

@RSully
Copy link
Author

RSully commented Oct 18, 2014

That's a good point I overlooked: there aren't even any 0.x releases of Cargo from what I can see 😦.

Maybe I should close this until they start tagging versions?

@DomT4
Copy link
Member

DomT4 commented Oct 18, 2014

I'd await feedback from one of the maintainers to be sure, but my gut feeling is that Homebrew won't be able to support Cargo until they start tagging releases that both work every time and don't make any sudden, unexpected changes outside of that release schedule.

@diimdeep
Copy link

Last time I checked Cargo can't be compiled with current Rust version, that's why It is recommended to use Cargo with nightly Rust

@RSully
Copy link
Author

RSully commented Oct 19, 2014

Alright then, we should revisit this once a release of Cargo is tagged.

@RSully RSully closed this as completed Oct 19, 2014
@DomT4
Copy link
Member

DomT4 commented Oct 19, 2014

SGTM 👍

@kron4eg
Copy link

kron4eg commented Apr 4, 2015

Now when rust 1.0.0 beta came out, it's time to review this issue

@DomT4
Copy link
Member

DomT4 commented Apr 4, 2015

Are Cargo tagging usable releases yet?

@kron4eg
Copy link

kron4eg commented Apr 4, 2015

@DomT4 nope :(

@DomT4
Copy link
Member

DomT4 commented Apr 4, 2015

I guess that's the primary problem. We'd probably need tagged releases that won't break against Rust stable.

@lloeki
Copy link
Contributor

lloeki commented Apr 14, 2015

Seems like somehow cargo has a peculiar versioning scheme:

At the moment there aren't concrete plans to make releases of Cargo. The Cargo nightly that corresponds to releases of Rust is in this file: https://github.com/rust-lang/rust-packaging/blob/master/cargo-revs.txt. Note that it's only set up to permanently record cargo revisions for stable releases of Rust.

That is, a cargo release is whatever gets packaged within a rust release. Currently (rust 1.0.0-beta) this is (look for the SHA1):

$ ./cargo --version
cargo 0.0.1-pre-nightly (84d6d2c 2015-03-31) (built 2015-03-31)

@lloeki
Copy link
Contributor

lloeki commented Apr 14, 2015

We'd probably need tagged releases that won't break against Rust stable.

There are two distinct situations one may have to consider:

  1. building cargo against homebrew's rust
  2. running cargo against homebrew's rust

Which one are we talking about here? Since cargo needs to fetch a cargo snapshot to build itself, it may not be that far of a stretch to allow the build process to fetch a nightly rust (as done by .travis.install.deps.sh, which is part of the README-documented workflow), at least while this is not solved. If the cargo crew isn't keen for tagging releases, maybe will this be a candidate for homebrew-head-only?

FWIW here's what I came up with, which builds the only cargo tag release (0.0.1-pre), as well as HEAD:

class Cargo < Formula
  homepage "https://crates.io"
  head "https://github.com/rust-lang/cargo", :using => :git
  version "0.0.1-pre"
  url "https://github.com/rust-lang/cargo/archive/v0.0.1-pre.tar.gz"
  sha256 "3c61260e8511fec344033a888f5dfcf3f0f13de86eecffd5903023082f475e5a"

  option "with-local-rust", "Build with Homebrew's rust"

  depends_on "cmake" => :build
  depends_on "python" => :build
  depends_on "pkg-config" => :build
  depends_on "curl" => :build unless build.with? "local-rust"
  depends_on "openssl"
  depends_on "rust"

  def install
    if build.head?
      system "git", "submodule", "update", "--init"
    end

    args = []
    if build.with? "local-rust"
      args << "--local-rust-root=#{Formula["rust"].opt_prefix}"
    else
      system "./.travis.install.deps.sh"
      args << "--local-rust-root=\"$PWD\"/rustc"
    end
    args << "--prefix=#{prefix}"
    system "./configure", *args
    system "make"
    system "make", "install"

    rm_rf prefix/"lib/rustlib/components"
    rm_rf prefix/"lib/rustlib/install.log"
    rm_rf prefix/"lib/rustlib/rust-installer-version"
    rm_rf prefix/"lib/rustlib/uninstall.sh"
  end

  test do
    system "#{bin}/cargo"
  end
end

@MikeMcQuaid
Copy link
Member

Seems to me cargo should be part of the Rust formula.

@lloeki
Copy link
Contributor

lloeki commented Apr 14, 2015

My thought exactly (way more inline with upstream), but a separate formula was best to get acquainted with the build sequence.

@MikeMcQuaid
Copy link
Member

My thought exactly (way more inline with upstream), but a separate formula was best to get acquainted with the build sequence.

👍 Would you be able to submit a pull request? I can't promise we'll be able to merge it immediately but it definitely seems like something we'll want.

@lloeki
Copy link
Contributor

lloeki commented Apr 15, 2015

Will do.

@lloeki
Copy link
Contributor

lloeki commented Apr 15, 2015

Rust formula including cargo is theoretically ready: waiting for rust build to complete, which takes approximately ages and a half.

lloeki added a commit to lloeki/homebrew that referenced this issue Apr 15, 2015
This follows discussion on Homebrew#33322, where it has been hypothesized that
the best course of action may very well be to include cargo in the rust
formula. Reasons include:

- upstream packages releases with cargo
- cargo has no formal versioning rules, merely binding a particular
  cargo nightly to a given rust release
- cargo needs a non feature-gated rust to build
- cargo needs to fetch cargo to bootstrap itself (at the make stage)

The most practical way to get the cargo version bound to a rust release
is to download a binary rust release and run cargo -V, which shows the
SHA1 it was built from. This is what has been done for the beta.

Alternatively, building with --HEAD relaxes all version constrains and
builds both from their respective master HEADs.

Curl is a dependency of .travis.install.deps.sh while both curl and
python are a dependency of make (via src/etc/dl-snapshot.py) to download
a cargo snapshot. Each one makes respective use of a src/rustversion.txt
and a src/snapshots.txt file, combined with some very lighteight
processing, to find the required downloads.

Thus it may be possible to include fetched downloads as resources to
improve cacheability and reduce the dependency profile, but this
requires patching of .travis.install.deps.sh, that currently
unconditionally downloads its stuff. Simply putting the cargo snapshot
in the right place ($(TARGET_ROOT)/snapshot/cargo) will certainly make
the makefile happy, as long as the proper filename unmangling is done
(see src/etc/dl-snapshot.py). Still, configure wants to probe for
python. Staying KISS, no patching has been done here: make it work, make
it right, make it fast.
@lloeki
Copy link
Contributor

lloeki commented Apr 15, 2015

==> Summary
/usr/local/Cellar/rust/1.0.0-beta: 5628 files, 291M, built in 81.0 minutes

Off we go onto the aforementioned Pull Request.

lloeki added a commit to lloeki/homebrew that referenced this issue Apr 15, 2015
This follows discussion on Homebrew#33322, where it has been hypothesized that
the best course of action may very well be to include cargo in the rust
formula. Reasons include:

- upstream packages releases with cargo
- cargo has no formal versioning rules, merely binding a particular
  cargo nightly to a given rust release
- cargo needs a non feature-gated rust to build
- cargo needs to fetch cargo to bootstrap itself (at the make stage)

The most practical way to get the cargo version bound to a rust release
is to download a binary rust release and run cargo -V, which shows the
SHA1 it was built from. This is what has been done for the beta.

Alternatively, building with --HEAD relaxes all version constrains and
builds both from their respective master HEADs.

Curl is a dependency of .travis.install.deps.sh while both curl and
python are a dependency of make (via src/etc/dl-snapshot.py) to download
a cargo snapshot. Each one makes respective use of a src/rustversion.txt
and a src/snapshots.txt file, combined with some very lighteight
processing, to find the required downloads.

Thus it may be possible to include fetched downloads as resources to
improve cacheability and reduce the dependency profile, but this
requires patching of .travis.install.deps.sh, that currently
unconditionally downloads its stuff. Simply putting the cargo snapshot
in the right place ($(TARGET_ROOT)/snapshot/cargo) will certainly make
the makefile happy, as long as the proper filename unmangling is done
(see src/etc/dl-snapshot.py). Still, configure wants to probe for
python. Staying KISS, no patching has been done here: make it work, make
it right, make it fast.
lloeki added a commit to lloeki/homebrew that referenced this issue Apr 16, 2015
This follows discussion on Homebrew#33322, where it has been hypothesized that
the best course of action may very well be to include cargo in the rust
formula. Reasons include:

- upstream packages releases with cargo
- cargo has no formal versioning rules, merely binding a particular
  cargo nightly to a given rust release
- cargo needs a non feature-gated rust to build
- cargo needs to fetch cargo to bootstrap itself (at the make stage)

The most practical way to get the cargo version bound to a rust release
is to download a binary rust release and run cargo -V, which shows the
SHA1 it was built from. This is what has been done for the beta.

Alternatively, building with --HEAD relaxes all version constrains and
builds both from their respective master HEADs.

Curl is a dependency of .travis.install.deps.sh while both curl and
python are a dependency of make (via src/etc/dl-snapshot.py) to download
a cargo snapshot. Each one makes respective use of a src/rustversion.txt
and a src/snapshots.txt file, combined with some very lighteight
processing, to find the required downloads.

Thus it is be possible to include fetched downloads as resources to
improve cacheability and reduce the dependency profile as long as one
maintains consistency between each build component.
lloeki added a commit to lloeki/homebrew that referenced this issue Apr 16, 2015
This follows discussion on Homebrew#33322, where it has been hypothesized that
the best course of action may very well be to include cargo in the rust
formula. Reasons include:

- upstream packages releases with cargo
- cargo has no formal versioning rules, merely binding a particular
  cargo nightly to a given rust release
- cargo needs a non feature-gated rust to build
- cargo needs to fetch cargo to bootstrap itself (at the make stage)

The most practical way to get the cargo version bound to a rust release
is to download a binary rust release and run cargo -V, which shows the
SHA1 it was built from. This is what has been done for the beta.

Alternatively, building with --HEAD relaxes all version constrains and
builds both from their respective master HEADs.

Curl is a dependency of .travis.install.deps.sh while both curl and
python are a dependency of make (via src/etc/dl-snapshot.py) to download
a cargo snapshot. Each one makes respective use of a src/rustversion.txt
and a src/snapshots.txt file, combined with some very lighteight
processing, to find the required downloads.

Thus it is be possible to include fetched downloads as resources to
improve cacheability and reduce the dependency profile as long as one
maintains consistency between each build component.
lloeki added a commit to lloeki/homebrew that referenced this issue Apr 16, 2015
This follows discussion on Homebrew#33322, where it has been hypothesized that
the best course of action may very well be to include cargo in the rust
formula. Reasons include:

- upstream packages releases with cargo
- cargo has no formal versioning rules, merely binding a particular
  cargo nightly to a given rust release
- cargo needs a non feature-gated rust to build
- cargo needs to fetch cargo to bootstrap itself (at the make stage)

The most practical way to get the cargo version bound to a rust release
is to download a binary rust release and run cargo -V, which shows the
SHA1 it was built from. This is what has been done for the beta.

Alternatively, building with --HEAD relaxes all version constrains and
builds both from their respective master HEADs.

Curl is a dependency of .travis.install.deps.sh while both curl and
python are a dependency of make (via src/etc/dl-snapshot.py) to download
a cargo snapshot. Each one makes respective use of a src/rustversion.txt
and a src/snapshots.txt file, combined with some very lighteight
processing, to find the required downloads.

Thus it is be possible to include fetched downloads as resources to
improve cacheability and reduce the dependency profile as long as one
maintains consistency between each build component.
lloeki added a commit to lloeki/homebrew that referenced this issue Apr 16, 2015
This follows discussion on Homebrew#33322, where it has been hypothesized that
the best course of action may very well be to include cargo in the rust
formula. Reasons include:

- upstream packages releases with cargo
- cargo has no formal versioning rules, merely binding a particular
  cargo nightly to a given rust release
- cargo needs a non feature-gated rust to build
- cargo needs to fetch cargo to bootstrap itself (at the make stage)

The most practical way to get the cargo version bound to a rust release
is to download a binary rust release and run cargo -V, which shows the
SHA1 it was built from. This is what has been done for the beta.

Alternatively, building with --HEAD relaxes all version constrains and
builds both from their respective master HEADs.

Curl is a dependency of .travis.install.deps.sh while both curl and
python are a dependency of make (via src/etc/dl-snapshot.py) to download
a cargo snapshot. Each one makes respective use of a src/rustversion.txt
and a src/snapshots.txt file, combined with some very lighteight
processing, to find the required downloads.

Thus it is be possible to include fetched downloads as resources to
improve cacheability and reduce the dependency profile as long as one
maintains consistency between each build component.
lloeki added a commit to lloeki/homebrew that referenced this issue Apr 16, 2015
This follows discussion on Homebrew#33322, where it has been hypothesized that
the best course of action may very well be to include cargo in the rust
formula. Reasons include:

- upstream packages releases with cargo
- cargo has no formal versioning rules, merely binding a particular
  cargo nightly to a given rust release
- cargo needs a non feature-gated rust to build
- cargo needs to fetch cargo to bootstrap itself (at the make stage)

The most practical way to get the cargo version bound to a rust release
is to download a binary rust release and run cargo -V, which shows the
SHA1 it was built from. This is what has been done for the beta.

Alternatively, building with --HEAD relaxes all version constrains and
builds both from their respective master HEADs.

Curl is a dependency of .travis.install.deps.sh while both curl and
python are a dependency of make (via src/etc/dl-snapshot.py) to download
a cargo snapshot. Each one makes respective use of a src/rustversion.txt
and a src/snapshots.txt file, combined with some very lighteight
processing, to find the required downloads.

Thus it is be possible to include fetched downloads as resources to
improve cacheability and reduce the dependency profile as long as one
maintains consistency between each build component.
lloeki added a commit to lloeki/homebrew that referenced this issue Apr 17, 2015
This follows discussion on Homebrew#33322, where it has been hypothesized that
the best course of action may very well be to include cargo in the rust
formula. Reasons include:

- upstream packages releases with cargo
- cargo has no formal versioning rules, merely binding a particular
  cargo nightly to a given rust release
- cargo needs a non feature-gated rust to build
- cargo needs to fetch cargo to bootstrap itself (at the make stage)

The most practical way to get the cargo version bound to a rust release
is to download a binary rust release and run cargo -V, which shows the
SHA1 it was built from. This is what has been done for the beta.

Alternatively, building with --HEAD relaxes all version constrains and
builds both from their respective master HEADs.

Curl is a dependency of .travis.install.deps.sh while both curl and
python are a dependency of make (via src/etc/dl-snapshot.py) to download
a cargo snapshot. Each one makes respective use of a src/rustversion.txt
and a src/snapshots.txt file, combined with some very lighteight
processing, to find the required downloads.

Thus it is be possible to include fetched downloads as resources to
improve cacheability and reduce the dependency profile as long as one
maintains consistency between each build component.
lloeki added a commit to lloeki/homebrew that referenced this issue Apr 21, 2015
This follows discussion on Homebrew#33322, where it has been hypothesized that
the best course of action may very well be to include cargo in the rust
formula. Reasons include:

- upstream packages releases with cargo
- cargo has no formal versioning rules, merely binding a particular
  cargo nightly to a given rust release
- cargo needs a non feature-gated rust to build
- cargo needs to fetch cargo to bootstrap itself (at the make stage)

The most practical way to get the cargo version bound to a rust release
is to download a binary rust release and run cargo -V, which shows the
SHA1 it was built from. This is what has been done for the beta.

Alternatively, building with --HEAD relaxes all version constrains and
builds both from their respective master HEADs.

Curl is a dependency of .travis.install.deps.sh while both curl and
python are a dependency of make (via src/etc/dl-snapshot.py) to download
a cargo snapshot. Each one makes respective use of a src/rustversion.txt
and a src/snapshots.txt file, combined with some very lighteight
processing, to find the required downloads.

Thus it is be possible to include fetched downloads as resources to
improve cacheability and reduce the dependency profile as long as one
maintains consistency between each build component.
lloeki added a commit to lloeki/homebrew that referenced this issue Apr 30, 2015
This follows discussion on Homebrew#33322, where it has been hypothesized that
the best course of action may very well be to include cargo in the rust
formula. Reasons include:

- upstream packages releases with cargo
- cargo has no formal versioning rules, merely binding a particular
  cargo nightly to a given rust release
- cargo needs a non feature-gated rust to build
- cargo needs to fetch cargo to bootstrap itself (at the make stage)

The most practical way to get the cargo version bound to a rust release
is to download a binary rust release and run cargo -V, which shows the
SHA1 it was built from. This is what has been done for the beta.

Alternatively, building with --HEAD relaxes all version constrains and
builds both from their respective master HEADs.

Curl is a dependency of .travis.install.deps.sh while both curl and
python are a dependency of make (via src/etc/dl-snapshot.py) to download
a cargo snapshot. Each one makes respective use of a src/rustversion.txt
and a src/snapshots.txt file, combined with some very lighteight
processing, to find the required downloads.

Thus it is be possible to include fetched downloads as resources to
improve cacheability and reduce the dependency profile as long as one
maintains consistency between each build component.
lloeki added a commit to lloeki/homebrew that referenced this issue Apr 30, 2015
This follows discussion on Homebrew#33322, where it has been hypothesized that
the best course of action may very well be to include cargo in the rust
formula. Reasons include:

- upstream packages releases with cargo
- cargo has no formal versioning rules, merely binding a particular
  cargo nightly to a given rust release
- cargo needs a non feature-gated rust to build
- cargo needs to fetch cargo to bootstrap itself (at the make stage)

The most practical way to get the cargo version bound to a rust release
is to download a binary rust release and run cargo -V, which shows the
SHA1 it was built from. This is what has been done for the beta.

Alternatively, building with --HEAD relaxes all version constrains and
builds both from their respective master HEADs.

Curl is a dependency of .travis.install.deps.sh while both curl and
python are a dependency of make (via src/etc/dl-snapshot.py) to download
a cargo snapshot. Each one makes respective use of a src/rustversion.txt
and a src/snapshots.txt file, combined with some very lighteight
processing, to find the required downloads.

Thus it is be possible to include fetched downloads as resources to
improve cacheability and reduce the dependency profile as long as one
maintains consistency between each build component.
MikeMcQuaid pushed a commit that referenced this issue Apr 30, 2015
This follows discussion on #33322, where it has been hypothesized that
the best course of action may very well be to include cargo in the rust
formula. Reasons include:

- upstream packages releases with cargo
- cargo has no formal versioning rules, merely binding a particular
  cargo nightly to a given rust release
- cargo needs a non feature-gated rust to build
- cargo needs to fetch cargo to bootstrap itself (at the make stage)

The most practical way to get the cargo version bound to a rust release
is to download a binary rust release and run cargo -V, which shows the
SHA1 it was built from. This is what has been done for the beta.

Alternatively, building with --HEAD relaxes all version constrains and
builds both from their respective master HEADs.

Curl is a dependency of .travis.install.deps.sh while both curl and
python are a dependency of make (via src/etc/dl-snapshot.py) to download
a cargo snapshot. Each one makes respective use of a src/rustversion.txt
and a src/snapshots.txt file, combined with some very lighteight
processing, to find the required downloads.

Thus it is be possible to include fetched downloads as resources to
improve cacheability and reduce the dependency profile as long as one
maintains consistency between each build component.

Closes #38674.

Signed-off-by: Mike McQuaid <[email protected]>
Noctem pushed a commit to Noctem/homebrew that referenced this issue May 2, 2015
This follows discussion on Homebrew#33322, where it has been hypothesized that
the best course of action may very well be to include cargo in the rust
formula. Reasons include:

- upstream packages releases with cargo
- cargo has no formal versioning rules, merely binding a particular
  cargo nightly to a given rust release
- cargo needs a non feature-gated rust to build
- cargo needs to fetch cargo to bootstrap itself (at the make stage)

The most practical way to get the cargo version bound to a rust release
is to download a binary rust release and run cargo -V, which shows the
SHA1 it was built from. This is what has been done for the beta.

Alternatively, building with --HEAD relaxes all version constrains and
builds both from their respective master HEADs.

Curl is a dependency of .travis.install.deps.sh while both curl and
python are a dependency of make (via src/etc/dl-snapshot.py) to download
a cargo snapshot. Each one makes respective use of a src/rustversion.txt
and a src/snapshots.txt file, combined with some very lighteight
processing, to find the required downloads.

Thus it is be possible to include fetched downloads as resources to
improve cacheability and reduce the dependency profile as long as one
maintains consistency between each build component.

Closes Homebrew#38674.

Signed-off-by: Mike McQuaid <[email protected]>
@Homebrew Homebrew locked and limited conversation to collaborators Feb 17, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants