Release - Next major 0.12.0 - Tracker

[pinkforest]

What would you all lovely people want to see from the next major 0.12.0 breaking version?

I may have assigned you since I would :purple_heart: some feedback from you that would be nice to be included -

Anyone else ofc. more than welcome to give feedback as well :))

If there isn't an issue yet for something that should be included please raise issue so we can

Please note I have skipped the non-breaking issues which can be fixed without major "breaking" change.

There is some category crossover, some of them cannot be done without the other and some can resolve others etc. the usual.

Scanning / Change Analysis Inputs

• [ ] #6
• [ ] #22 - Sub-dependency tree inclusion problem
• [ ] https://github.com/rust-secure-code/cargo-geiger/issues/102#issuecomment-620641852 - Consume -Funsafe-code :fire:
• [ ] #101 - Plutonium! - reddit:the most illegal code
• [ ] #102 - Macro expansion
• [ ] #103 - Ignore non-rust code
• [ ] #145 - Ignore Data (DER)
• [ ] #190 --Ignore dependencies analysis (it still builds em though)
• [ ] #206 - Virtual manifests
• [ ] #240
• [x] #269 - @ilyatrefilov :rocket:

Improve Reporting Output

• [ ] #10 - Hook to comrak to convert from Github markdown to provide HTML output
• [ ] #22 - Improve pub unsafe fn reporting checking whether these are called at all
• [ ] #82
• [ ] #92 - Errors are currently exposed raw JSON - Make them Human readable
• [ ] 53 , 119 and #137 - Improve and Differentiate on Test/Development Reporting vs Actual production Deps
• [ ] #145 - Improve Warnings | Data / Compile warnings (Minor version fix perhaps)
• [ ] #152
• [ ] https://github.com/rust-secure-code/wg/issues/43 - Support for distributed analytics contributions

Cargo De-Couple - Working currently by @pinkforest

• [ ] #63
• [ ] #69 - Use as sub-process only
• [ ] #81 - Ensure required-features and --bin and --lib separation honored
• [ ] #93 - Ensure required-features and --bin and --lib separation honored (tree_magic)
• [ ] #149 - Also use RusTLS ?
• [ ] #181 - Nightly features
• [ ] #226 - CompileOptions Reform / gate & mirror CLI options

Cargo Logistics

• [ ] #93 - Honor Cargo.toml required-features as well as --bin and --lib separation (tree_magic)
• [ ] #95 - Re-Use Target Directory (architecture mix-up problem)
• [ ] #113 - Re-Use Target Directory (relay the flag)
• [ ] #168 - Re-Use Target Directory (prevent removal of directory)

Parsing / Handling

• [ ] #179 - [link] directive
• [ ] #12 - dtolnay/syn - this crate deserves it's own issue :)
• [ ] #11

Geiger.rs

• [ ] #63
• [ ] #150 - Will include the badges as feature there
• [x] #213
• [ ] https://github.com/rust-secure-code/wg/issues/43

Moonshot

Not repo specific stuff but interesting related ideas however

• https://github.com/rust-secure-code/wg/issues/42

• 50

[pinkforest]

As part of major CLI Options changes

There is a tracker issue tying together all the changes in #226

Geiger Dev/Build run types will mirror cargo logically and as result will be separate reports.

All required opts for 0.12.0 will be documented there

[anderejd]

What would you all lovely people want to see from the next major 0.12.0 breaking version?

You already added it to the list, #69 is the one I really wanted to get done when I was actively working on this project 🤩

If everything in the list above gets done for 0.12 then that's a serious upgrade 💪

[anderejd]

Are there any users of cargo geiger here that use the tool in a large project in CI or in the development environment? To get feedback from any such users would be super interesting to me.

[pinkforest]

I'll be using it - in geiger.rs - for the whole ecosystem (crates.io) in distributed environment so I've de-coupled the runner and CLI with traits -

It's taking a bit time - sorry - to do this properly (I hope) as there is a lot of breaking things that need to be addressed same time.

Also I've added clap3 derive as an option to drive CLI and also environment variables only that can be toggled via features that will be handy for CI and reduced binary size / build time.

The runner will support both cargo and clippy but there is a lot of re-structure happening so the de-coupling is major breaking change I'm running on different branch.

I'm still unsure how I can add github etc. repositories but I am thinking that we add a support for reporting the CI run to geiger.rs or even a CD like something like geekbench that would avoid me having to scale geiger.rs to run on all the linked repos too :)

[anderejd]

That's exciting to hear :) Looking forward to following your work, maybe I can find some time to make small contributions along the way to 0.12.

[ilyatrefilov]

I looked up the code in scan part, and.. shouldn't we make it multithreaded? Now it seems to take too much time to scan solid package ( tokio in my experience), but if user does this , should he care about smth other on the machine? When it goes to cloud, that is smth to reason about, didn't find some improvement on this in list , so comes the question in :)

[pinkforest]

It's something worth thinking & iterating about -

The runners themselves run multiplexed via multi-process but introducing threading to scanning part has it's own merits -

Can we raise a separate issue about where we can talk & iterate it and I can link it to here into the table.

[pinkforest]

Very nice @ilyatrefilov went and did threading for even in the current codebase scanning, tokio-rs/tokio now just "snaps" now and with a good dependency to have rayon - issue #269 .. and also fixed one of the with "Failure to match" on earlier PR .. good stuff! :rocket: