5 ms·

This is local developer tooling we're talking about, however. It doesn't need to run on those machines.

kbenson 10y ago
You want your devs all running the exact same version of the compiler. The last thing you want is someone with a slightly different version than used by everyone else (and production!) which writes some code that compiles and runs fine without problems, but crashes or exhibits a bug in testing, QA, or worst case, production. Having something like that occasionally gum up your development pipeline is a good reason for pegging tool versions (depending on the type of tool). Having things use rustup is great. Don't assume that's sufficient for certain populations of users (and a populations you really may want, such as enterprise). At best, they'll use rustup as a basis to start some other packaging, but even that's risky because rustup is complex, and it's hard to contain all the variables unless you're very careful about exactly what version you use with it, so then you're packaging rustup, and then package what it created. Easier at that point to just skip rustup. It's all about reproducibility, which is king in enterprise. Rustup is about ease of use, and easy iteration. Enterprise already sacrifice that on the alter of reproducibility, so it's really not a selling point for them. It's great for everyone else, it just has less to offer for this subgroup.
- Manishearth 10y ago
  Right, you can pin to a nightly for tooling. The solution I proposed does not affect reproducability, since you would only use the nightly when running local tools.
  - kbenson 10y ago
    My point is that it's not always a local tool. Sometimes what you consider a local tool might be something run on a QA or testing box, which needs to be tightly controlled to make sure that the difference between a tooling item intalled and a required library that is in production is closely tracked, and the tooling library needs to match exactly what's actually installed locally for devs. Think CI tool chains, automated testing, etc. A certain percentage of organizations where see "let's use this program that dynamically downloads and builds a program, which we can ask for a specific version if we want" as unacceptable because either it requires remote sources, it requires specific configuration which isn't tracked automatically or enforced, or both. It's not about whether it's possible, it's about whether you're meeting the needs of the target audience. I don't believe rustup is meeting those needs in some cases. The important distinction is that possible does not imply acceptable.
    - Manishearth 10y ago
      I get that, but the solution is still possible and should be acceptable -- keep a One True Copy of a .multirust directory which you install on all testing servers and dev setups. No network necessary. Enterprise setups already do far more complicated things with pypi clones and whatnot. Again, having rustup installed with two preinstalled and pinned compilers should not be much different, acceptability-wise, from having one preinstalled and pinned compiler.
      - kbenson 10y ago
        I humbly suggest that saying something "should be acceptable" when it's been explained at length that, regardless of whether you think it's acceptable, other people do not think so, is exactly the problem yazaddaruvala was describing above. If you are trying to market to a population, you need to take their needs seriously with a good faith effort. Not understanding is fine. Doing a cost-benefit analysis and determining there's just no resources for what's needed is fine. Telling people that their needs are unjustified doesn't come across very well to those that still feel those needs.
        Manishearth 10y ago
        I'm saying it should be acceptable in the parameters presented to me so far. Please explain why two compilers with a switching program is bad, whereas one compiler isn't. I am trying to understand the needs and come up with a solution, but so far they have been presented in bits an pieces. I am working off what has been told to me so far and my own experiences in locked down environments, which admittedly weren't as locked down as the ones you describe. I am also comparing with what other "enterprise-ready" languages require for tooling to try and ubderstand what is "acceptable". You keep telling me that I am not aware of the needs of enterprise users. Fine, I concede that. Please explain them to me. My intention in providing possible "acceptable" solutions is to find out what use case prevents them from working and see how Rust can address that. I am not telling people their needs are unjustified. ...this is also why I implored it to be further discussed in email, while the media are similar I am able to discuss more clearly there.

You want your devs all running the exact same version of the compiler. The last thing you want is someone with a slightly different version than used by everyone else (and production!) which writes some code that compiles and runs fine without problems, but crashes or exhibits a bug in testing, QA, or worst case, production. Having something like that occasionally gum up your development pipeline is a good reason for pegging tool versions (depending on the type of tool). Having things use rustup is great. Don't assume that's sufficient for certain populations of users (and a populations you really may want, such as enterprise). At best, they'll use rustup as a basis to start some other packaging, but even that's risky because rustup is complex, and it's hard to contain all the variables unless you're very careful about exactly what version you use with it, so then you're packaging rustup, and then package what it created. Easier at that point to just skip rustup. It's all about reproducibility, which is king in enterprise. Rustup is about ease of use, and easy iteration. Enterprise already sacrifice that on the alter of reproducibility, so it's really not a selling point for them. It's great for everyone else, it just has less to offer for this subgroup.

Manishearth 10y ago
Right, you can pin to a nightly for tooling. The solution I proposed does not affect reproducability, since you would only use the nightly when running local tools.
- kbenson 10y ago
  My point is that it's not always a local tool. Sometimes what you consider a local tool might be something run on a QA or testing box, which needs to be tightly controlled to make sure that the difference between a tooling item intalled and a required library that is in production is closely tracked, and the tooling library needs to match exactly what's actually installed locally for devs. Think CI tool chains, automated testing, etc. A certain percentage of organizations where see "let's use this program that dynamically downloads and builds a program, which we can ask for a specific version if we want" as unacceptable because either it requires remote sources, it requires specific configuration which isn't tracked automatically or enforced, or both. It's not about whether it's possible, it's about whether you're meeting the needs of the target audience. I don't believe rustup is meeting those needs in some cases. The important distinction is that possible does not imply acceptable.
  - Manishearth 10y ago
    I get that, but the solution is still possible and should be acceptable -- keep a One True Copy of a .multirust directory which you install on all testing servers and dev setups. No network necessary. Enterprise setups already do far more complicated things with pypi clones and whatnot. Again, having rustup installed with two preinstalled and pinned compilers should not be much different, acceptability-wise, from having one preinstalled and pinned compiler.
    - kbenson 10y ago
      I humbly suggest that saying something "should be acceptable" when it's been explained at length that, regardless of whether you think it's acceptable, other people do not think so, is exactly the problem yazaddaruvala was describing above. If you are trying to market to a population, you need to take their needs seriously with a good faith effort. Not understanding is fine. Doing a cost-benefit analysis and determining there's just no resources for what's needed is fine. Telling people that their needs are unjustified doesn't come across very well to those that still feel those needs.
      - Manishearth 10y ago
        I'm saying it should be acceptable in the parameters presented to me so far. Please explain why two compilers with a switching program is bad, whereas one compiler isn't. I am trying to understand the needs and come up with a solution, but so far they have been presented in bits an pieces. I am working off what has been told to me so far and my own experiences in locked down environments, which admittedly weren't as locked down as the ones you describe. I am also comparing with what other "enterprise-ready" languages require for tooling to try and ubderstand what is "acceptable". You keep telling me that I am not aware of the needs of enterprise users. Fine, I concede that. Please explain them to me. My intention in providing possible "acceptable" solutions is to find out what use case prevents them from working and see how Rust can address that. I am not telling people their needs are unjustified. ...this is also why I implored it to be further discussed in email, while the media are similar I am able to discuss more clearly there.