Tool that makes upgrading cargo dependencies easier

[jdm]

This is the tracking issue for the work necessary for this NCSU project description.

[totallybradical]

Hi Josh,

An update and a question for you:

• We've gone ahead and created a GitHub repo for our development on this tool per your suggestion.
• As far as parsing the Cargo.lock, are we only concerned with the packages? (i.e. the information after each [[package]] heading). From what I've gathered, the dependency listings under [[root]] are those that the user has specified within the .toml so the [[packages]] are really what's important.

I just want to make sure I understand exactly what information to parse out of the Cargo.lock.

[jdm]

This is a good question. It might make sense to ignore Cargo.lock to start with and only focus on the Cargo.toml files, since Cargo.lock includes dependencies of other dependencies, which cannot necessarily be updated in the same way as the direct dependencies specified in Servo's Cargo.toml files.

[jdm]

That being said, the versions of Servo's dependencies listed in Cargo.lock can be more specific than the ones in Servo's Cargo.toml files (ie. 0.5.3 vs. 0.5), so I guess we do need to parse Cargo.lock to obtain that.

[totallybradical]

That makes sense.

So with regards to the Cargo.toml files you're mentioning, this refers to all the Cargo.toml files within the "components" subdirectory, correct?

To re-word the initial description a bit based on my understanding it sounds like this tool should:

1. Parse the Cargo.lock for all packages and their versions
2. Compare these versions to the most up-to-date versions (crates.io local copy) * need some logic to determine which versions to take? *
3. With any differences, update all instances of that dependency version in all of the Cargo.toml files (within components subdirectory?)
4. Run the update command
5. Manage all of this with git best practices

Am I understanding this correctly? Apologies for the redundancy but I'm trying to understand what information we are trying to extract, and how we are making decisions within the tool.

Thanks

[jdm]

Yes, that looks right. Note that there are TOML files in ports/ as well as in the root directory.

[totallybradical]

Yeah I noticed those files when I was searching. I take it we should update those as well then.

Another question: Is there any criteria to be used when determining if a package should be upgraded?

For example, in the sample Cargo.lock (here) there's a dependency for "assert_cli". The version noted in the lock file is 0.2.2. The current version is now listed as 0.3.0. Do we only want non-major upgrades? Do we want to always upgrade to the latest?

For starters, we're planning a simple check for ANY version greater than the version in the lock file. But we can attempt to implement specific criteria if desired.

Thank you again

[jdm]

Starting with accepting major upgrades sounds fine to me.

[chbrown13]

Hey Josh, one more quick question. Can we assume users will have the same operating system/version of python/etc.?

[jdm]

The same as what?

[chbrown13]

The same as everyone else using the servo dependency tool. For example will everyone have Python 3 or will all machines be using Windows 10?

[jdm]

You should be able to assume the same Python version, but that's all.

[chbrown13]

Ok, thanks

[totallybradical]

Regarding the update command, I've gone ahead and installed Rust on my laptop for development. I seem to be able to run the "cargo update -p" command and it updates the registry when I run it so that's good.

However, I see it's also possible to just run "cargo update" in order to update all dependencies (source). Given that blindly updating all dependencies can cause many problems I can see why we want to use the -p flag and specify which packages to update. So I'm wondering what our tool might do in order to selectively update certain packages (which I know I asked earlier). Perhaps we should consider the option to approve upgrades while running the tool (y/n type prompt)? Otherwise, we could implement some automatic criteria for choosing which packages to update as I mentioned previously (minor upgrades vs major upgrades). Or maybe some logic that you and the servo team already follow as it pertains to updates.

Any input you can provide would be appreciated!

[jdm]

Let's go with upgrading everything to start. I'm having trouble identifying meaningful criteria that we could use.

[jdm]

https://github.com/chbrown13/servo-dependency-tool

[atouchet]

Is this tool completed or in use at all? Does Dependabot accomplish what this issue is asking for?

[jdm]

Yes, Dependabot is a more effective solution.