PSA: Support landed for `cros workon start/stop <path>`

[Alex Klein]

If you don't use cros workon you can stop reading now.

TL;DR: cros workon -b $BOARD start ./source_code.c

Support for path arguments has landed for cros workon!

If you find yourself making changes to a file but you're not sure what package it belongs to, rather than manually looking up the package you can now just pass the file path to cros workon. It should work with files and directories, and inside and outside of the chroot (but the `cros-workon-$BOARD` wrappers are still only available inside).

The commands are the same as before, you can just pass a path instead of the package name.

If a file affects multiple packages, for now it'll just select the first one and tell you what the other packages were. This is just matching what it does when you start/stop a package it can't resolve uniquely. If different behaviors could be useful, let me know what the use case is, I'd be happy to look into it.

The caveat is that it's not a fast operation (~45-60s). Passing a package is going to be much faster if you already know it, but hopefully passing a file will be much faster than manually looking it up.

I do have some plans to make additional tools with the path->package lookup functionality, but if you have a use case where it could be helpful, I'd love to hear about it!

Thanks,

Alex

[Allen Webb]

Thanks for doing this.

I wonder if it would be possible to cache the mapping from paths to package names (e.g. store the mapping in a pickle). You could check the git hash of chromiumos-overlay to determine when the cache is stale. This might significantly speed up the feature.

It might be good to add equery-like functionality to cros-workon for listing the cros-workon packages for a path if that doesn't exist already.

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
https://groups.google.com/a/chromium.org/group/chromium-os-dev
---
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-d...@chromium.org.

[John Bates]

This is glorious. Thanks Alex.

[Junichi Uekawa (上川純一)]

Yay, thank you for working on this.

2021年9月1日(水) 1:19 'Alex Klein' via Chromium OS Development <chromiu...@chromium.org>:

I would like to use this on `compile this file` in my emacs

 

Thanks,

Alex

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
https://groups.google.com/a/chromium.org/group/chromium-os-dev
---
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-d...@chromium.org.

--

Junichi Uekawa
Google

[Evan Benn]

This is great! I got an error when I tested (bug filed), does it print the name of the package it finds for subsequent emerge commands?

One side effect of this is that a misspelled package now takes 30+ seconds to return an error. 

Possibly we could require users to specify paths explicitly with either ./<file> or workon start -- <file> 

Thanks

[Miriam Zimmerman]

This is awesome!! Thank you!

https://memegen.corp.google.com/9842022097125827

[Alex Klein]

I think it'll be possible to speed it up in the future, but getting it right is going to be a little tricky. That said, a lot of the edge cases with caching this functionality don't apply to the cros workon use case -- e.g. generating it, changing src paths in a 9999 ebuild and cros workon start the package -- so we may be able to do a cache specifically for cros workon at least.

I've been thinking about adding a stand alone tool for it recently too. I was originally hesitant, I don't like the idea of forcing devs to manually string things together to perform a useful operation when it could be directly integrated, but it seems like it may be useful enough that I'll be too much of a bottleneck here.

Thanks,

Alex

[Alex Klein]

I saw your bug come in, thanks for the report! I'll be doing some digging first chance I get.

Thank you for asking about printing the found package, I hadn't considered that carefully enough. It does log that info, but not at the default log level. Right now you'll need to run it with `--log-level info` or `--verbose` to get that output. If you forget to do that, you can check what is worked on with `cros workon list`, or just run it again and you'll get a warning that you're already working on the package. I'll get that fixed up so that'll display by default ASAP, though.

Yeah, I disliked the misspelling = long wait too. My original implementation limited it to ".", but that was just too restrictive. Forcing /, ./, or -- to distinguish paths from packages may be doable, though, I'll look into it!

Thanks,

Alex

[Alex Klein]

I was over thinking the misspelling issue, just checking if the possible path exists is sufficient to avoid the long calculations since there's no reason to pass a one that doesn't exist. I have CLs up for that and the logging, so hopefully those will be landing soon. The stack is here if you want to follow them: crrev.com/c/3149339.

Thanks,

Alex