sigstore-python
pyenv
sigstore-python | pyenv | |
---|---|---|
4 | 261 | |
210 | 36,723 | |
0.5% | 1.3% | |
9.3 | 8.9 | |
7 days ago | 7 days ago | |
Python | Roff | |
GNU General Public License v3.0 or later | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
sigstore-python
-
How to improve Python packaging, or why 14 tools are at least 12 too many
You could use `pip-compile` if you want full pinning. That's what we do on another project -- we use GitHub Actions with `pip-compile` to provide a fully frozen copy of the dependency tree for users who'd like that[1].
In the context of `pip-audit`, that makes a little less sense: most of our dependencies are semantically versioned, and we'd rather users receive patches and fixes to our subdependencies automatically, rather than having to wait for us to release a corresponding fix version. Similarly, we expect users to install `pip-audit` into pre-existing virtual environments, meaning that excessive pinning will produce overly conservative dependency conflict errors.
[1]: https://github.com/sigstore/sigstore-python/tree/main/instal...
-
Use `Python -m Pip`
The conflicting advice is a serious problem.
I hope you'll forgive me for adding one additional piece of advice: for many Python packages, the only packaging metadata you need is `pyproject.toml`. You don't even need `setup.py` anymore, so long as you're using a build backend that supports editable installs with `pyproject.toml`.
Here's an example of a Python package that does everything in `pyproject.toml`[1]. You should be able to copy that into any of your projects, edit it to match your metadata, and everything will work exactly as if you have a `setup.cfg` or `setup.py`.
[1]: https://github.com/sigstore/sigstore-python
-
Bundling binary tools in Python wheels
You're right, both the infrastructure and metadata for cryptographic signatures on Python packages (both wheels and sdists) isn't quite there yet.
At the moment, we're working towards the "e2e" scheme you've described by adding support for Sigstore[1] certificates and signatures, which will allow any number of identities (including email addresses and individual GitHub release workflows) to sign for packages. The integrity/availability of those signing artifacts will in turn be enforced through TUF, like you mentioned.
You can follow some of the related Sigstore-in-Python work here[2], and the ongoing Warehouse (PyPI) TUF work here[3]. We're also working on adding OpenID Connect token consumption[4] to Warehouse itself, meaning that you'll be able to bootstrap from a trusted GitHub workflow to a PyPI release token without needing to share any secrets.
[1]: https://www.sigstore.dev/
[2]: https://github.com/sigstore/sigstore-python
[3]: https://github.com/pypa/warehouse/pull/10870
[4]: https://github.com/pypa/warehouse/pull/11272
- Project sigstore (free software signing service) just released a library to sign and verify python packages
pyenv
-
Install Asdf: One Runtime Manager to Rule All Dev Environments
If you have a requirement for multiple, specific Python versions, why not just use pyenv?
https://github.com/pyenv/pyenv
-
Setup and Use Pyenv in Python Applications
For more information visit: pyenv repository
- Pyenv – lets you easily switch between multiple versions of Python
-
How to Create Virtual Environments in Python
Note that virtual environments assume you are using the same global version of Python. Often, this is not the case and additional tools like pyenv can be used alongside virtual environments when you need to switch between versions of Python itself on your local machine.
-
How to debug Django inside a Docker container with VSCode
Python version manager pyenv
-
Integrating GPT in Your Project: Create an API for Anything Using LangChain and FastAPI
First of all, install the Python virtual environment from these links: 1 and 2. I developed my GPT-based API in Python version 3.8.18. Pick any Python versions >= 3.7.
-
Manage your Python Project End-to-End with PDM
Note: Most modern systems will probably have a system environment that meets this requirement, but if yours does not or if you prefer not to install anything in your system environment (even if it's just PDM) check out asdf or pyenv to help install and manage additional Python environments.
-
Introducing Flama for Robust Machine Learning APIs
When dealing with software development, reproducibility is key. This is why we encourage you to use Python virtual environments to set up an isolated environment for your project. Virtual environments allow the isolation of dependencies, which plays a crucial role to avoid breaking compatibility between different projects. We cannot cover all the details about virtual environments in this post, but we encourage you to learn more about venv, pyenv or conda for a better understanding on how to create and manage virtual environments.
-
Is KDE Desktop really snappier than XFCE these days as claimed?
For Python, with your use case I would avoid system packages, no matter the distro. It sounds like it would be worth setting up pyenv and working exclusively with virtual environments.
-
Python Versions and Release Cycles
For OSX there is homebrew or pyenv (pyenv is another solution on Linux). As pyenv compiles from source it will require setting up XCode (the Apple IDE) tools to support this which can be pretty bulky. Windows users have chocolatey but the issue there is it works off the binaries. That means it won't have the latest security release available since those are source only. Conda is also another solution which can be picked up by Visual Studio Code as available versions of Python making development easier. In the end it might be best to consider using WSL on Windows for installing a Linux version and using that instead.
What are some alternatives?
sampleproject - A sample project that exists for PyPUG's "Tutorial on Packaging and Distributing Projects"
Poetry - Python packaging and dependency management made easy
publishing-python-packages - Examples and exercises for Publishing Python Packages from Manning Books 🐍 📦 ⬆️
asdf - Extendable version manager with support for Ruby, Node.js, Elixir, Erlang & more
pigar - :coffee: A tool to generate requirements.txt for Python project, and more than that. (IT IS NOT A PACKAGE MANAGEMENT TOOL)
Pipenv - Python Development Workflow for Humans.
Nuitka - Nuitka is a Python compiler written in Python. It's fully compatible with Python 2.6, 2.7, 3.4, 3.5, 3.6, 3.7, 3.8, 3.9, 3.10, and 3.11. You feed it your Python app, it does a lot of clever things, and spits out an executable or extension module.
miniforge - A conda-forge distribution.
auditwheel - Auditing and relabeling cross-distribution Linux wheels.
virtualenv - Virtual Python Environment builder
pip-audit - Audits Python environments, requirements files and dependency trees for known security vulnerabilities, and can automatically fix them
Pew - A tool to manage multiple virtual environments written in pure python