separate/split requirements.txt

viper-framework / viper

Binary analysis and management framework

Other

1.54k stars 350 forks source link

separate/split requirements.txt #531

Closed frennkie closed 7 years ago

frennkie commented 7 years ago

Not an issue, more a question/idea/suggestion:

How about splitting the requirements.txt into separate files based on who would need what:

1) requirements-base.txt ( or "-core.txt" )

all python requirements that are absolutely necessary to run the Viper CLI (e.g. SQLAlchemy)

2) requirements-modules.txt

all python requirements for all available modules (so if you would like to be able to use all features of all modules you simply install all of these)

3) requirements-web.txt

all python requirements for the web (currently bottle etc., later maybe Django + extensions)

4) requirements-dev.txt

all python requirements for dev, test and docs stuff

0) requirements.txt

-r requirements-base.txt
-r requirements-modules.txt

Ideally the requirements-modules.txt could be auto generated from the imports of all modules.. but that could be done later on..

Rafiot commented 7 years ago

Sounds good to me :)

Rafiot commented 7 years ago

I just started to play with it, and I have a question: do we want to not display the modules who are missing dependencies? The most obvious example would be the misp module, which won't work at all if pymisp isn't installed.

Advantage:

you have a clear view of what you can do in the interface if you don't have all the dependencies

Disadvantage:

Support, we will have people coming "module X isn't there, what is going on" when they simply didn't install the dependency.

frennkie commented 7 years ago

[...] to not display the modules [...]

Not display where? In the help and tab-tab view?

Support, we will have people coming "module X isn't there, what is going on" when they simply didn't install the dependency.

My idea for this is that the about command (or another new command) will print a list of all modules and gives the status of each module (e.g. "OK", "missing python dependencies (pymisp, ..)", "missing system dependencies (exiftool, ..)").. something in that direction. Then the user can check the status and decide whether he installs missing stuff or simply accepts that not all modules are available..

Rafiot commented 7 years ago

in the help and the tab-tab view, yes

The about command solution definitely works for me!

frennkie commented 7 years ago

In the Archiver class I already implemented something similar (each sub class has to specify a list with system and python dependencies which I can then check and act on the result).

If we want to do the same thing with the modules we would need to extend the Module class (in abstracts) .. shouldn't be a problem, right?

Rafiot commented 7 years ago

nope, it isn't a problem

frennkie commented 7 years ago

done