codescan do not install on M1 Macs and Windows WSL

[tardyp]

My team wants to work and contribute to scancode, and members of our teams have M1 Macs, or work on Windows WSL/WSL2.

scancode currently does not install with those setups, because it insists on installing binaries from wheels that are not compatibles with those systems.

I have worked today on this issue for the m1 and came up with a few PRs to fix this state

aboutcode-org/extractcode#18
inveniosoftware-contrib/intbitset#75
aboutcode-org/typecode#17

With those three PRs applied in a virtualenv, I can install scancode, provided that I comment the following lines in scancode's setup.cfg

extractcode[full] >= 21.2.24
typecode[full] >= 21.2.24

Shall we create a [full] extra-requires on scancode as well, so that we can have a lightweight install of scancode possible?

What is your recommendation?

[pombredanne]

Shall we create a [full] extra-requires on scancode as well, so that we can have a lightweight install of scancode possible?
What is your recommendation?

For this use case there is the "scancode-toolkit-mini" build that is exactly the same code as "scancode-toolkit" but uses this setup instead https://github.com/nexB/scancode-toolkit/blob/6c43e29f446c948ec581995fa59665594341eef8/setup-mini.cfg which does not require these two by default:

extractcode[full] >= 21.2.24
typecode[full] >= 21.2.24

(you could need to install them separately or with the extra_requires pip install scancode-toolkit-mini[full]

[pombredanne]

I have worked today on this issue for the m1 and came up with a few PRs to fix this state

aboutcode-org/extractcode#18
inveniosoftware-contrib/intbitset#75
aboutcode-org/typecode#17

This is awesome!
As it happens, I maintain or co-maintain all of these, so that makes it easy enough.

My team wants to work and contribute to scancode, and members of our teams have M1 Macs, or work on Windows WSL/WSL2.

M1 would be awesome to support with native wheels but there would be a need to have a build and a test machine.
As for WSL, I am all in to add support for WSL2 (which may actually work already?) but I am not sure WSL may be possible to get working.

[tardyp]

you could need to install them separately or with the extra_requires pip install scancode-toolkit-mini[full]

I guess this method does not work well for a developer. Is there a way to use your setup-mini.cfg with "pip install -e" ?

I get that the scancode[full] is not very intuitive for new users, but this method is actually raising the bar for new developer to jump in by a fair amount, IMHO.

I am not sure if it is worth to support all those different setups officially. I can think of freebsd, alpine, which are also fairly popular options among devs, but also fairly niche, so maybe not worth it.

M1 would be awesome to support with native wheels but there would be a need to have a build and a test machine.

That is indeed the issue for wheels only packages. There are very few native wheels provided for m1, and I guess users of niche systems understand that and are fine as long as source packages are available.
In that case, this is not really possible, I understand your approach and agree I don't see better alternative.

I like the idea of support tiers of rust https://doc.rust-lang.org/nightly/rustc/platform-support.html

I would suggest to have the current platforms tier1 supported by nextB, and have others like m1 community-supported.
A little bit more work (installing libarchive/libmagic in the system), but still supported as cheap as possible for the maintainers.

As per WSL2, I agree with you it is probably to switch to that instead of standard windows, it might simplify the maintainance. I've seen another issue for that.