Simplify process interface

[djc]

This makes the Process abstraction much easier to understand (in my opinion) by avoiding a trait abstraction (which had only a single implementation) and explicitly relying on the enum variants. Removes 250 lines of code and the need for the enum-dispatch dependency.

[rami3l]

@djc Wow, thank you so much for the hard work! I will definitely find some time to review the patch.

OTOH I guess we can put this in 1.28? I really want to make 1.27.1 "patch only".

[djc]

I'm fine with holding this back until after 1.27.1 is released, though I also think the risk is pretty limited.

[rbtcollins]

I'm fine in principle with this. there is a similar structure in the fork of home that we use - https://github.com/rbtcollins/home/blob/master/src/lib.rs#L41 - so you may want to tackle that, or perhaps we pick up the discussion about having home natively support our needs again.

[rbtcollins]

One nit you can ignore, and a file rename request - we don't use the mod.rs style in rustup.

[rbtcollins]

Not sure this vertical white space helps anything much :)

[djc]

Personally I find the delineation of larger code blocks to help understand the structure of the code.

[rbtcollins]

please call this file src/process.rs

[rbtcollins]

In terms of when to merge, this will conflict with #3367, which is already ready to merge but also waiting for 1.28 to open.

[djc]

I'm fine in principle with this. there is a similar structure in the fork of home that we use - https://github.com/rbtcollins/home/blob/master/src/lib.rs#L41 - so you may want to tackle that, or perhaps we pick up the discussion about having home natively support our needs again.

I think we're just using upstream version 0.5.4 right now?

One nit you can ignore, and a file rename request - we don't use the mod.rs style in rustup.

This is not actually true:

djc-2021 cfg-debug rustup $ find . -name "mod.rs"
./tests/suite/mod.rs
./download/tests/support/mod.rs
./src/diskio/mod.rs
./src/test/mock/mod.rs
./src/dist/component/mod.rs
./src/dist/mod.rs
./src/utils/mod.rs

Personally, I've grown to substantially dislike the style where the parent module root lives in a separate directory from the child modules, since it keeps them farther away in the directory view of IDEs and such, making the code harder to navigate at least for me. I've tried it on several projects after the 2018 edition went stable and have ended up mostly reverting to the earlier style -- and I checked to see that this style is already quite common in the rustup codebase.

In terms of when to merge, this will conflict with #3367, which is already ready to merge but also waiting for 1.28 to open.

Well, it has quite a bit of unaddressed review feedback -- but, I'm happy to let #3367 land before this PR.

[rbtcollins]

Oh, I missed all that feedaback, will look at it.

Personally, I've grown to substantially dislike the style where the parent module root lives in a separate directory from the child modules, since it keeps them farther away in the directory view of IDEs and such, making the code harder to navigate at least for me. I've tried it on several projects after the 2018 edition went stable and have ended up mostly reverting to the earlier style -- and I checked to see that this style is already quite common in the rustup codebase.

Ah, its hangovers we hadn't refactored. We've tended not to make nonfunctional changes for various not particularly good reasons.

Happy for us to have a discussion then about what style the project should take, but I've found the opposite - foo.rs means the module file path is always the same, whether or not the module has child modules, or is a leaf itself where a directory with just the module file would be tedious.

[djc]

Personally, I've grown to substantially dislike the style where the parent module root lives in a separate directory from the child modules, since it keeps them farther away in the directory view of IDEs and such, making the code harder to navigate at least for me. I've tried it on several projects after the 2018 edition went stable and have ended up mostly reverting to the earlier style -- and I checked to see that this style is already quite common in the rustup codebase.

Ah, its hangovers we hadn't refactored. We've tended not to make nonfunctional changes for various not particularly good reasons.

Happy for us to have a discussion then about what style the project should take, but I've found the opposite - foo.rs means the module file path is always the same, whether or not the module has child modules, or is a leaf itself where a directory with just the module file would be tedious.

Right. My preference would be to use single files when there are no child modules (in separate files), but I think as soon as we move to a directory it's better to keep everything contained in the same directory -- rather than having the code for a single module spread over two places, one file for the "root" and a directory containing further files for the children.

@rami3l any thoughts?

[rami3l]

Right. My preference would be to use single files when there are no child modules (in separate files), but I think as soon as we move to a directory it's better to keep everything contained in the same directory -- rather than having the code for a single module spread over two places, one file for the "root" and a directory containing further files for the children.

@rami3l any thoughts?

@djc @rbtcollins You're referring to foo/mod.rs vs foo.rs right? I use the latter in my projects, since I use path searching instead of path navigating (in Neovim, but previously in VSCode as well). When you use searching it's a nightmare to encounter a whole bunch of */mod.rss.

I do understand that this is a niche, and foo/mod.rs is much better if you're navigating thru the paths (probably has something to do with VSCode not wanting to put foo/ next to foo.rs in the explorer view). However, considering the compatibility for both cases I personally prefer foo.rs.

That being said, I'm eventually okay with either way as long as they are consistent (looks like that isn't the case currently), and BTW we should probably get rid of that dist::dist thing somewhere in the codebase which gets me every time...