Remove indirect dependencies

[thinrope]

While working on packaging latest plaso for Gentoo, I think I see two python modules (idna,cffi) which are not referenced in any code, yet they are installed by some of the scripts. I suggest to have them removed from dependencies.ini and requirements.txt.

Those are only indirect dependencies as follows:

• idna <- requests
• cffi <- dfvfs TBC!

This concerns plaso-20240409 on Gentoo installed from my pkalin overlay, as there is no official plaso support on Gentoo yet.

NOTE: Description was edited as follows:

• remove mention of cryptography (patch had to be reverted anyway)
• explain those are indirect dependencies

[joachimmetz]

cryptography should be no longer there, idna and cffi we would need to check.

[joachimmetz]

looks like idna was a requirement of cryptography and requests, cryptography is no longer used, but let me check requests

[joachimmetz]

Looks like idna still is a dependency of requests https://github.com/psf/requests/blob/main/setup.cfg#L6 . I would need to look why it was explicitly added instead of it being an implicit dependency. I recommend we keep that one for now.

[joachimmetz]

And cffi is a dependency of xattr https://github.com/xattr/xattr/blob/main/pyproject.toml#L15

[joachimmetz]

I would need to assess first, the reason for these indirect dependencies were added. Likely due to one of the packaging/environments failing to include them.

[joachimmetz]

Looks like cffi was added for cryptography but this predates the inclusion of xattr 221a298

[joachimmetz]

Idna was explicitly added for requests 8871cd9

[thinrope]

I'll work on this a bit more, but here are my thoughts:

• no indirect deps should be present in dependencies.ini and requirements.txt, they may be in some of the CICD files
• given that I removed those 3 and tests passed, we need better tests :-) May be something that uses IDNA url for example

[joachimmetz]

no indirect deps should be present

Unfortunately the "should" here is one of those theory versus reality arguments. They were added because they were needed.

• Given they are used indirectly anyway, they not abundant, we can take the time to take a closer look why they were originally added
• Many things have changed since they were added it could be that they are no longer needed.

we need better tests :-)

tests can always be improved

[thinrope]

I am digging around and so far I don't see any direct use of cffi nor idna across the projects even:

• ("from cffi import" OR "import cffi") AND (org:libyal OR org:log2timeline)
• ("from idna import" OR "import idna") AND (org:libyal OR org:log2timeline)

(Disclaimer: The above two ways are the only standard ways to use a Python module, AFAIK)

While dfvfs also lists cffi as direct dep, I see no place where it is used. Based on blame, cffi is a remains of pycrypto->cryptography move 5 years ago (and now cryptography is no longer used). Let me know if we need another issue for this (since different project).

[joachimmetz]

(Disclaimer: The above two ways are the only standard ways to use a Python module, AFAIK)

Python has many "standard" ways of using modules.

I'll have a closer looks when time permits. Maybe this was msi or Pyinstaller related.