setup.py

$ cd pypi
$ python setup.py build
Traceback (most recent call last):
  File "setup.py", line 8, in <module>
    version = re.search('^VERSION\s*=\s*\'v(\d\.\d\.\d)\'', open('sshaudit/sshaudit.py').read(), re.M).group(1)
FileNotFoundError: [Errno 2] No such file or directory: 'sshaudit/sshaudit.py'

$ python setup.py build
Traceback (most recent call last):
  File "setup.py", line 11, in <module>
    with open("sshaudit/README.md", "rb") as f:
FileNotFoundError: [Errno 2] No such file or directory: 'sshaudit/README.md'

There is no sshaudit.py in pypi/sshaudit/, I suspect you are using a symbolic link locally. Also it’s not the right filename (dash missing). Same for the README.

So the workaround was:

$ cp ../ssh-audit.py sshaudit/sshaudit.py
$ cp ../README.md sshaudit/README.md

[jtesta]

When I created this fork, there was no setup.py. I created it myself when I needed to make a PyPI package. I remember running into errors that didn’t make sense, so I just tried random things until I stumbled on something that worked. At that point, I crossed this off my list and moved on to other things. So that explains why things are so… non-standard.

I’m certainly open to fixing things up!

[jugmac00]

Yep, all that sounds good. After the upcoming v2.3.0 release is done, we can get started on that (I’m hoping it’ll be done by the end of this week). The only other thing I’d like to note is that ssh-audit.py should remain as a stub which imports all the code from ssh_audit.py. That way users can still run the program like they did before without installing it (“./ssh-audit.py target”).

I bet you know, but ssh-audit will be still available after installation.

Also, there is a nifty trick I saw at another cli app. You can create a bash wrapper for the Python script, so you can run ./app without installing it and still use a src directory which… see next paragraph 😃 https://github.com/mgedmin/check-python-versions/blob/master/check-python-versions

(But let’s do not hide this in the ssh-audit.py file 😃)

• move source code into src directory Since this isn’t standard Python practice, we don’t need to do it. I’d rather re-organize the project to adhere to Python conventions.

Actually, it is an emerging standard, which is followed by tons and tons of projects, and many older projects convert to it.

Python is a very evolving language, and especially the packaging story was a tough one, but it is getting better and better.

Just a few projects which converted to the src strategy… https://github.com/python-attrs/attrs https://github.com/pallets/flask almost all Zope projects (hundreds) https://github.com/getsentry/sentry https://github.com/python-pillow/Pillow https://github.com/pypa/pip https://github.com/pytest-dev/pytest https://github.com/twisted/twisted https://github.com/Pylons/pyramid https://github.com/pyca/cryptography …

There many good reasons… some are outlined in the following articles… btw both Hynek and Paul are cpython core developers, and Paul is even a member of the Python packaging authority. So it is not somebody on the internet 😃

https://hynek.me/articles/testing-packaging/ https://web.archive.org/web/20170615032800/https://enotuniq.org/ https://blog.ganssle.io/articles/2019/08/test-as-installed.html

• split main module into smaller ones

Yes, I’d love to do this. I’ve been wanting to do it for a while, but with all the other problems we had (broken tests, tabs instead of spaces, etc), I pushed it off. Now we’re in the position to finally do it!

For this to become a smooth experience, a src directory is (almost) mandatory.

I’ll get this going myself after we fix the other issues, above.

There is no need to rush anything. I still think a one time more or less breaking change (ssh-audit.py -> bash wrapper ssh-audit) could enable a very convenient future development of the application.

My background is not security - I maintain several mid sized, and one huge Python application (all proprietary) - that is certainly a different story compared to this application here. Though, a straight project layout will make it easier in the future.

If you ever want to chat about any Python related topics, I am sure we’ll find a time slot which both fits us (US vs EU based).