nmap: update to depend on python2 for ndiff and zenmap; add 7.93

[dpzmick]

I'm not sure how to do this exactly. It's failing CI due to a missing python2

this is also still getting issues on m1 darwin for me (but not my linux machines)

[spackbot-app]

Hi @dpzmick! I noticed that the following package(s) don't yet have maintainers:

• nmap

Are you interested in adopting any of these package(s)? If so, simply add the following to the package class:

    maintainers = ["dpzmick"]

If not, could you contact the developers of this package and see if they are interested? You can quickly see who has worked on a package with spack blame:

$ spack blame nmap

Thank you for your help! Please don't add maintainers without their consent.

You don't have to be a Spack expert or package developer in order to be a "maintainer," it just gives us a list of users willing to review PRs or debug issues relating to this package. A package can have multiple maintainers; just add a list of GitHub handles of anyone who wants to volunteer.

[tldahlgren]

As you note, the package audits don't like use of python2. Spack deprecated Python2 in v0.19 and plans to remove its support.

PKG-DIRECTIVES: 2 issues found
[13](https://github.com/spack/spack/actions/runs/3860953155/jobs/6581619077#step:6:14)
1. nmap: dependency on python@:2 cannot be satisfied by known versions of python
[14](https://github.com/spack/spack/actions/runs/3860953155/jobs/6581619077#step:6:15)
    happening in /home/runner/work/spack/spack/var/spack/repos/builtin/packages/nmap/package.py
[15](https://github.com/spack/spack/actions/runs/3860953155/jobs/6581619077#step:6:16)
    known versions of python are 3.11.0, 3.10.8, 3.10.7, 3.10.6, 3.10.5, 3.10.4, 3.10.3, 3.10.2, 3.10.1, 3.10.0, 3.9.15, 3.9.14, 3.9.13, 3.9.12, 3.9.11, 3.9.10, 3.9.9, 3.9.8, 3.9.7, 3.9.6, 3.9.5, 3.9.4, 3.9.3, 3.9.2, 3.9.1, 3.9.0, 3.8.15, 3.8.14, 3.8.13, 3.8.12, 3.8.11, 3.8.10, 3.8.9, 3.8.8, 3.8.7, 3.8.6, 3.8.5, 3.8.4, 3.8.3, 3.8.2, 3.8.1, 3.8.0, 3.7.15, 3.7.14, 3.7.13, 3.7.12, 3.7.11, 3.7.10, 3.7.9, 3.7.8, 3.7.7, 3.7.6, 3.7.5, 3.7.4, 3.7.3, 3.7.2, 3.7.1, 3.7.0, 3.6.15
[16](https://github.com/spack/spack/actions/runs/3860953155/jobs/6581619077#step:6:17)
2. nmap: dependency on python@:2 cannot be satisfied by known versions of python
[17](https://github.com/spack/spack/actions/runs/3860953155/jobs/6581619077#step:6:18)
    happening in /home/runner/work/spack/spack/var/spack/repos/builtin/packages/nmap/package.py
[18](https://github.com/spack/spack/actions/runs/3860953155/jobs/6581619077#step:6:19)
    known versions of python are 3.11.0, 3.10.8, 3.10.7, 3.10.6, 3.10.5, 3.10.4, 3.10.3, 3.10.2, 3.10.1, 3.10.0, 3.9.15, 3.9.14, 3.9.13, 3.9.12, 3.9.11, 3.9.10, 3.9.9, 3.9.8, 3.9.7, 3.9.6, 3.9.5, 3.9.4, 3.9.3, 3.9.2, 3.9.1, 3.9.0, 3.8.15, 3.8.14, 3.8.13, 3.8.12, 3.8.11, 3.8.10, 3.8.9, 3.8.8, 3.8.7, 3.8.6, 3.8.5, 3.8.4, 3.8.3, 3.8.2, 3.8.1, 3.8.0, 3.7.15, 3.7.14, 3.7.13, 3.7.12, 3.7.11, 3.7.10, 3.7.9, 3.7.8, 3.7.7, 3.7.6, 3.7.5, 3.7.4, 3.7.3, 3.7.2, 3.7.1, 3.7.0, 3.6.15
[19](https://github.com/spack/spack/actions/runs/3860953155/jobs/6581619077#step:6:20)
Error: Process completed with exit code 1.

[cosmicexplorer]

Hi David! Thanks so much for this contribution!!!

(1) What version of nmap is expected to fix this? It would be preferable to add a version constraint with an upper bound to the when clause in order to shut off this dependency for later nmap versions automatically. Please let me know if the documentation on version ranges is useful as I am working on it in a separate PR.

(2) What link did you use to determine this information (so we can see if the expected release date changes)? I use nmap infrequently but might file as maintainer.

[dpzmick]

Funny seeing you here haha!

(1) The next release of nmap will add py3 support to their internal tools. I can add a version constraint for this dep easily here.

(2) I determined this from digging around in their repo, and this changelog: https://nmap.org/changelog.html
(2.1) Their configure script explicitly checks for python2 up until the unreleased version

To reply to both comments (@tldahlgren) do you all prefer disabling these features completely until the next nmap release, or should we keep the py2 dep but gate it by version? Either way changes will need to be made at update time so I sort of prefer just removing these feature flags until the next nmap release

[tldahlgren]

Great question. I'm torn as I don't like completely removing an option that can soon be restored. But purists won't want the code until it/they are available.

[dpzmick]

I pushed the "just remove the features" version, but I'm seeing a different build issue now on my linux machine, and on my m1 mac.

On linux there's an openssl issue, on m1 there seems to be a build system race. I'll keep poking at this

[tldahlgren]

As you note, the package audits don't like use of python2. Spack deprecated Python2 in v0.19 and plans to remove its support.

[..snip..]

Perhaps it's better to remove those options and document that the features cannot be used if/until Python3 is supported by them?

[tldahlgren]

I like this approach. Shows these are options and explains they can be re-enabled once the codes support a reasonable (😉 ) Python.

[dpzmick]

okay, I believe I have fixed the mac build (with a bit of a hack). Is there a good way to check that all listed versions of this package build with any automation? I've just been checking the latest two

[dpzmick]

A simple

$ spack versions nmap --safe | xargs -I{} spack install nmap@{}

seems to do the trick. A number of the versions do not build. A few short logs here: https://gist.github.com/dpzmick/040ddafe401bb43d039efe474f462d5a

and a bunch of these versions depend on a deprecated openssl. I think these should all be cleaned up, but likely on a separate PR. This PR should be good to go!

Thanks for the feedback, let me know if there's anything else that needs adjusting

[tldahlgren]

I can successfully install the new version.

[tldahlgren]

I also made a few suggestions on comment wording.

@cosmicexplorer Did you want to re-review this PR?

[tldahlgren]

See suggested changes to wording of comments.

[tldahlgren]

See suggested changes to wording of comments.

Interesting. I hoped that the comment would replace the required changes status for my review.

[tldahlgren]

LGTM. Thanks for the changes!

@cosmicexplorer Did you want to comment on this PR?

[bernhardkaindl]

tldahlgren reviewed:

I like this approach. Shows these are options and explains they can be re-enabled once the codes support a reasonable (😉 ) Python.

Indeed. I tested the build on x86 and aarch64-linux, and since python2 is removed it's a great fix too!