pip-audit VS ipython

Next up is making sure, none of the dependencies used throughout the project brings with it any already identified security issue. The makefile target audit, invokes the handy tool pip-audit.

Here is my "one true" Makefile for Python projects[1]. The skeleton gets tweaked slightly each time, but it's served me well for 4+ years.

[1]: https://github.com/pypa/pip-audit/blob/main/Makefile

Why use this over the established https://pypi.org/project/pip-audit/ ?

https://pypi.org/project/pip-audit/ details usage and the GitHub Action install.

If it's pure Python, the only packaging file you need is `pyproject.toml`. You can fill that file with packaging metadata per PEP 518 and PEP 621, including using modern build tooling like flit[1] for the build backend and build[2] for the frontend.

With that, you entire package build (for all distribution types) should be reducible to `python -m build`. Here's an example of a full project doing everything with just `pyproject.toml`[3] (FD: my project).

[1]: https://github.com/pypa/flit

[2]: https://github.com/pypa/build

[3]: https://github.com/pypa/pip-audit

- repo: https://github.com/trailofbits/pip-audit rev: v2.4.3 hooks: - id: pip-audit args: [ "-r", "requirements.txt" ] ci: # Leave pip-audit to only run locally and not in CI # pre-commit.ci does not allow network calls skip: [ pip-audit ]

This is really nicely written; kudos to the author for compiling a great deal of information in a readable format.

If I can be forgiven one nitpick: Poetry does not use a PEP 518-style[1] build configuration by default, which means that its use of `pyproject.toml` is slightly out of pace with the rest of the Python packaging ecosystem. That isn't to say that it isn't excellent, because it is! But you the standards have come a long way, and you can now use `pyproject.toml` with any build backend as long as you use the standard metadata.

By way of example, here's a project that's completely PEP 517 and PEP 518 compatible without needing a setup.py or setup.cfg[2]. Everything goes through pyproject.toml.

[1]: https://peps.python.org/pep-0518/

[2]: https://github.com/trailofbits/pip-audit/blob/main/pyproject...

Checking could be done if something like this eventually shows up in safety or pip-audit.

Something like python's pip-audit. For commercial solutions I know there's Snyk and Jfrog we can always purchase, but I'm interested to see if there's an open-source tool that can do this.

If you’re already using ipython, this isn’t a problem because you’ll already need to download most of these dependencies anyway. But if you’re not using ipython… you’ll still need to download those dependencies.

!pip install is error-prone, it is better to use %pip install, ipython even warns about this, https://github.com/ipython/ipython/pull/12954/

The git history (here is the git blame) shows it has not been updated in 9 year. Looks like a documentation issue that you should open an issue against.

Do you know IPython? It is a modern Python console that extends the capabilities of the classic builtin Python shell by offering introspection, tab completion, syntaxing coloring, as well as history. If you don't know it, I can't recommend it enough. More information can be found in its GitHub page.

There is an IPython ticket on GitHub on the topic, but it's unclear if the problem has been solved.

For further documentation on ipython using the CLI, you can refer to the GitHub link or the documentation page.

> ??????_ Traceback (most recent call last): File "/home/nvaughn4/bin/miniconda3/envs/newprime/bin/ipython", line 11, in sys.exit(start_ipython()) File "/home/nvaughn4/bin/miniconda3/envs/newprime/lib/python3.6/site-packages/IPython/__init__.py", line 126, in start_ipython return launch_new_instance(argv=argv, **kwargs) File "/home/nvaughn4/bin/miniconda3/envs/newprime/lib/python3.6/site-packages/traitlets/config/application.py", line 658, in launch_instance app.start() File "/home/nvaughn4/bin/miniconda3/envs/newprime/lib/python3.6/site-packages/IPython/terminal/ipapp.py", line 356, in start self.shell.mainloop() File "/home/nvaughn4/bin/miniconda3/envs/newprime/lib/python3.6/site-packages/IPython/terminal/interactiveshell.py", line 563, in mainloop self.interact() File "/home/nvaughn4/bin/miniconda3/envs/newprime/lib/python3.6/site-packages/IPython/terminal/interactiveshell.py", line 554, in interact self.run_cell(code, store_history=True) File "/home/nvaughn4/bin/miniconda3/envs/newprime/lib/python3.6/site-packages/IPython/core/interactiveshell.py", line 2858, in run_cell raw_cell, store_history, silent, shell_futures) File "/home/nvaughn4/bin/miniconda3/envs/newprime/lib/python3.6/site-packages/IPython/core/interactiveshell.py", line 2880, in _run_cell elif self.should_run_async(raw_cell): File "/home/nvaughn4/bin/miniconda3/envs/newprime/lib/python3.6/site-packages/IPython/core/interactiveshell.py", line 2918, in should_run_async return _should_be_async(cell) File "/home/nvaughn4/bin/miniconda3/envs/newprime/lib/python3.6/site-packages/IPython/core/async_helpers.py", line 161, in _should_be_async code = compile(cell, "<>", "exec") UnicodeEncodeError: 'utf-8' codec can't encode characters in position 537-542: surrogates not allowed If you suspect this is an IPython 7.15.0 bug, please report it at: https://github.com/ipython/ipython/issues or send an email to the mailing list at [email protected] You can print a more detailed traceback right now with "%tb", or use "%debug" to interactively debug it. Extra-detailed tracebacks for bug-reporting purposes can be enabled via: %config Application.verbose_crash=True sys:1: RuntimeWarning: coroutine 'InteractiveShell.run_cell_async' was never awaited

There’s one I’ve come across recently here where you’re fighting against syntax highlighting with extra error context. https://github.com/ipython/ipython/issues/13446#issuecomment...

I see. https://github.com/ipython/ipython/issues/13529

You can automate setup for developers using this simple script:

https://github.com/ipython/ipython/pull/12091/files

And here’s a GitLab issue requesting support for blame-ignore:

https://gitlab.com/gitlab-org/gitlab/-/issues/31423

I don’t think there’s a corresponding GitHub request, but maybe if GitLab adds this feature GitHub will have some incentive to follow suit.