Closed noraj closed 4 years ago
References:
Couple things on this.
However, explicit relative imports are an acceptable alternative to absolute imports, especially when dealing with complex package layouts where using absolute imports would be unnecessarily verbose
warn
needs to be changed to warning
.gitignore
for now.stegoVeritas
Most of the imports are more succinct as relative imports, and so I'd like to keep them that way.
With relative import we can't call the script from anywhere and most importantly we can use it without install via setup.py so we can't package it in blackarch https://github.com/BlackArch/blackarch/pull/2754 (unfortunately we can't package it in the classic way with setup.py because you are using python-magic conflicting with the other python-magic (file-magic) https://github.com/bannsec/stegoVeritas/issues/10 so we are forced to package it in a virtual environement to get teh dependencies with pip).
Also there is no complex layout, there is never a depth higher than 3. So there is no ridiculous case such as:
I'm not intending to add anything to the
.gitignore
for now.
This could be remove is you prefer. Just cherry pick it when merging or I can do a revert commit.
Your import changes don't work. They completely break
stegoVeritas
Is that so? I tried and it was working.
$ git clone https://github.com/noraj/stegoVeritas.git
$ cd stegoVeritas
$ git checkout pep8
$ python -m venv venv
$ source venv/bin/activate
$ wget https://github.com/BlackArch/blackarch/blob/25ece8d2770dc67b358ebd3b16c46b8a2f3b9f7d/packages/stegoveritas/requirements.txt
$ pip install .
$ python stegoveritas/stegoveritas.py ~/Pictures/makepkg_not_war.png git:pep8
Running Module: SVImage
+---------------------------+----------+
| Image Format | Mode |
+---------------------------+----------+
| Portable network graphics | ColorMap |
+---------------------------+----------+
Running Module: MultiHandler
Exif
====
+---------------------+--------------------------------------------------------------------------------------------------------------------+
| key | value |
+---------------------+--------------------------------------------------------------------------------------------------------------------+
| SourceFile | /home/noraj/Pictures/makepkg_not_war.png |
| ExifToolVersion | 11.85 |
| FileName | makepkg_not_war.png |
| Directory | /home/noraj/Pictures |
| FileSize | 25 kB |
| FileModifyDate | 2020:02:10 23:25:44+01:00 |
| FileAccessDate | 2020:05:03 19:09:35+02:00 |
| FileInodeChangeDate | 2020:02:10 23:25:44+01:00 |
| FilePermissions | rw-r--r-- |
| FileType | PNG |
| FileTypeExtension | png |
| MIMEType | image/png |
| ImageWidth | 1920 |
| ImageHeight | 1080 |
| BitDepth | 8 |
| ColorType | Palette |
| Compression | Deflate/Inflate |
| Filter | Adaptive |
| Interlace | Noninterlaced |
| SRGBRendering | Relative Colorimetric |
| Palette | -,,988/..0//.--100211433322766544655877/--755333111555222---000422311...///6440..200533866,++.,,1//444777666888,,, |
| ImageSize | 1920x1080 |
| Megapixels | 2.1 |
+---------------------+--------------------------------------------------------------------------------------------------------------------+
Found something worth keeping!
PNG image data, 1920 x 1080, 8-bit colormap, non-interlaced
+--------+------------------+-------------------------------------------+-----------+
| Offset | Carved/Extracted | Description | File Name |
+--------+------------------+-------------------------------------------+-----------+
| 0xb4 | Carved | Zlib compressed data, default compression | B4.zlib |
| 0xb4 | Extracted | Zlib compressed data, default compression | B4 |
+--------+------------------+-------------------------------------------+-----------+
Totally working fine.
Again, this tool is a python package. It is not meant to be called with python stegoveritas/stegoveritas.py
. Your import changes make it work specifically for blackarch and break the intended use case.
If, as you say, you are installing it into a python virtual environment, then simply call it as everyone else does with the launcher installed as stegoVeritas
into your PATH
.
To check that your changes don't break anything, you can run pytest
the included tests
directory.
To check that your changes don't break anything, you can run pytest the included tests directory.
Right, I forgot to add the module name, now running pytest behave exactly the same in master branch or in pep8 branch.
I also add build/
in gitignore because this directory is created when running pytest.
If, as you say, you are installing it into a python virtual environment, then simply call it as everyone else does with the launcher installed as
stegoVeritas
into yourPATH
.
I fear it's not as simple as that. If you were using python-magic rather than the actual python-python-magic, packaging stegoVeritas would be as easy as that: https://github.com/BlackArch/blackarch-pkgbuilds/blob/master/PKGBUILD-python
But since we can't use python-python-magic
because it's conflicting with the official well know and used python-magic
we have to install python dependencies alone in a virtual env in a post install script like that and to make a wrapper that will source this virtual env when stegoveritas is called and then call the tool like that.
I tried without success not to call exec python /usr/share/$pkgname/$pkgname/$pkgname.py "\$@"
in the wrapper and add an additional python setup.py install --root="/usr/share/stegoveritas" --prefix='venv' -O1 --skip-build
and calling /usr/share/$pkgname/venv/bin/$pkgname "\$@"
in the wrapper instead.
If you see a way to package your tool with relative import in a virtual env, please tell us. Of course the easiest for us would be you to move from python-python-magic to python-magic so we could package stegoVeritas normally but in https://github.com/bannsec/stegoVeritas/issues/10 it seemed you prefer to keep python-python-magic.
I use it in a virtual environment every day without issues. It's best practice to do so.
For reference, install and use is as easy as:
virtualenv --python=$(which python3) myenv
source myenv/bin/activate
pip install stegoveritas
stegoveritas image.jpg
That's really all there is to it. And to your point about python magic, this is exactly why virtual environments were created and why it's a terrible idea to try to merge everyone's packages into a single environment (root/user or otherwise). It's simply asking for problems.