Also, I’ve wanted something like this several times in the past few years, particularly for stuff that starts out very ad hoc that I then want to share with someone. pip freeze is a little rough for that, and FawltyDeps seems at first blush like it’d smooth that out quite a bit.
I don‘t know if this makes the situation better or worse. First of all this could be used in supply chain attacks. Either when the import name (cv2) isn‘t the same as the package name (opencv-python) or if an attacker inserts a malicious import somewhere. Those are not checked by the common tools and therefore will not be detected.
Secondly some functions in a package need additional packages. Sometimes you can even choose between packages. (pandas.read_parquet needs pyarrow and/or fastparquet). This is impossible to resolve.
I‘m not convinced when you partially automate this that it actually improves the situation. Developers might be less sensitive when dealing with the mentioned topics. Ideally you write and execute isolated tests to verify the defined environment works. For software which are not libraries I would recommend using poetry or pipenv.
What would be useful is a tool which tracks which files were imported during testing to spot (or rather propose) unused/untested packages. Still this might lead to many false positives, but would be useful information nonetheless.
I love the name.
Also, I’ve wanted something like this several times in the past few years, particularly for stuff that starts out very ad hoc that I then want to share with someone.
pip freezeis a little rough for that, and FawltyDeps seems at first blush like it’d smooth that out quite a bit.Thanks for building and sharing this.
+1 for the name, and no need at all to mention the war.
I don‘t know if this makes the situation better or worse. First of all this could be used in supply chain attacks. Either when the import name (cv2) isn‘t the same as the package name (opencv-python) or if an attacker inserts a malicious import somewhere. Those are not checked by the common tools and therefore will not be detected.
Secondly some functions in a package need additional packages. Sometimes you can even choose between packages. (pandas.read_parquet needs pyarrow and/or fastparquet). This is impossible to resolve.
I‘m not convinced when you partially automate this that it actually improves the situation. Developers might be less sensitive when dealing with the mentioned topics. Ideally you write and execute isolated tests to verify the defined environment works. For software which are not libraries I would recommend using poetry or pipenv.
What would be useful is a tool which tracks which files were imported during testing to spot (or rather propose) unused/untested packages. Still this might lead to many false positives, but would be useful information nonetheless.