via https://framapiaf.org/@bitecode/114008017945593439

Market research

This post is only about dependency management, not package management, not build backends.

You know about these:

• uv

• poetry

• pipenv

You are probably not familiar with:

• pip-compile-multi

  (toposort, pip-tools)

You are defintely unfamiliar with:

• wreck

  (pip-tools, pip-requirements-parser)

pip-compile-multi creates lock files. Has no concept of unlock files.

wreck produces both lock and unlock files. venv aware.

Both sync dependencies across requirement files

Both act only upon requirements files, not venv(s)

Up to speed with wreck

You are familiar with .in and .txt requirements files.

.txt is split out into .lock and .unlock. The later is for packages which are not apps.

Create .in files that are interlinked with -r and -c. No editable builds. No urls.

(If this is a deal breaker feel free to submit a PR)

pins files

pins-*.in are for common constraints. The huge advantage here is to document why?

Without the documentation even the devs has no idea whether or not the constraint is still required.

pins-*.in file are split up to tackle one issue. The beauty is the issue must be documented with enough details to bring yourself up to speed.

Explain the origin of the issue in terms a 6 year old can understand.

Configuration

python -m pip install wreck

This is logging-strict pyproject.toml

[tool.wreck]
create_pins_unlock = false

[[tool.wreck.venvs]]
venv_base_path = '.venv'
reqs = [
    'requirements/dev',
    'requirements/kit',
    'requirements/pip',
    'requirements/pip-tools',
    'requirements/prod',
    'requirements/manage',
    'requirements/mypy',
    'requirements/tox',
]

[[tool.wreck.venvs]]
venv_base_path = '.doc/.venv'
reqs = [
    'docs/requirements',
]

dynamic = [
    "optional-dependencies",
    "dependencies",
    "version",
]

[tool.setuptools.dynamic]
dependencies = { file = ["requirements/prod.unlock"] }
optional-dependencies.pip = { file = ["requirements/pip.lock"] }
optional-dependencies.pip_tools = { file = ["requirements/pip-tools.lock"] }
optional-dependencies.dev = { file = ["requirements/dev.lock"] }
optional-dependencies.manage = { file = ["requirements/manage.lock"] }
optional-dependencies.docs = { file = ["docs/requirements.lock"] }
version = {attr = "logging_strict._version.__version__"}

Look how short and simple that is.

The only thing you have to unlearn is being so timid.

More venvs. More constraints and requirements complexity.

Do it

mkdir -p .venv || :;
pyenv version > .venv/python-version
python -m venv .venv

mkdir -p .doc || :;
echo "3.10.14" > .doc/python-version
cd .doc && python -m venv .venv; cd - &>/dev/null

. .venv/bin/activate
# python -m pip install wreck
reqs fix --venv-relpath='.venv'

There will be no avoidable resolution conflicts.

Preferable to do this within tox-reqs.ini

Details

TOML file format expects paths to be single quoted. The paths are relative without the last file suffix.

If pyproject.toml not in the cwd, --path='path to pyproject.toml'

create_pins_unlock = false tells wreck to not produce .unlock files for pins-*.in files.

DANGER

This is not for a faint of heart. If you can avoid it. This is for the folks who often say, Oh really, hold my beer!

For pins that span venv, add the file suffix .shared

e.g. pins-typing.shared.in

wreck deals with one venv at a time. Files that span venv have to be dealt with manually and carefully.

Issues

1. no support for editable builds

2. no url support

3. no hashs

4. your eyes will tire and brains will splatter on the wall, from all the eye rolling after sifting thru endless posts on uv and poetry and none about pip-compile-multi or wreck

5. Some folks love having all dependency managed within pyproject.toml These folks are deranged and its impossible to convince them otherwise. pyproject.toml is a config file, not a database. It should be read only.

6. a docs link on pypi.org is 404. Luckily there are two docs links. Should really just fix that, but it's left like that to see if anyone notices. No one did.

via https://mas.to/@davidism/113992575202656501

via https://mastodon.social/@treyhunner/113991275725668511

I'm working on a project that needs lots of toolbars on screen at once, even though not all of them will be used at the same time. So, I'm modelling this 'foldable' dock widget after what I remember Photoshop panels used to be like.

It's a work in progress, but would like to hear constructive suggestions.

https://blocks.programming.dev/0101100101/42c5d67f86c049baa3500aa38e439f8a

Working on a class that I'd like to use in a library (not for work) and think I'd appreciate external opinions!

If not, where else could I post code for critique? Thanks

Finally got around to creating a gh profile page

The design is to give activity insights on:

• what Issues/PRs working on

• future issues/PRs

• for fun, show off package mascots

All out of ideas. Any suggestions? How did you improve your github profile?

A common need in web applications is to create a form that allows the user to enter a list of items, with the number of items not known in advance. This is a pattern often used when entering user information, specifically for phone numbers or addresses, but has a lot of other uses as well.

Implementing this with Flask is surprisingly tricky, as it requires a combination of back and front end techniques working together.

via https://fosstodon.org/@programmylife/113962842059961474

MicroPie is a small and very fast Python web framework. It is designed with flexability and simplicity in mind. Check out the website or the GitHub project.

from MicroPie import App  

class MyApp(App):  

    async def index(self):  
        return 'Hello ASGI World!'  

app = MyApp()  # Run with `uvicorn app:app`  

>>> from kenobi import KenobiDB  

>>> db = KenobiDB('example.db')  

>>> db.insert({'name': 'Yoda', 'lightsaber': 'green'})  
True  

>>> db.search('lightsaber', 'green')  
[{'name': 'Yoda', 'lightsaber': 'green'}]  

via https://s.ovalerio.net/@dethos/113936362543993642

https://xcancel.com/charliermarsh/status/1884651482009477368

We’re building a new static type checker for Python, from scratch, in Rust.

From a technical perspective, it’s probably our most ambitious project yet. We’re about 800 PRs deep!

Like Ruff and uv, there will be a significant focus on performance.

The entire system is designed to be highly incremental so that it can eventually power a language server (e.g., only re-analyze affected files on code change).

Performance is just one of many goals, though.

For example: we're investing heavily in strong theoretical foundations and a consistent model of Python's typing semantics.

(We're lucky to have @carljm and @AlexWaygood on the team for many reasons, this is one of them.)

Another goal: minimizing false positives, especially on untyped code, to make it easier for projects to adopt a type checker and expand coverage gradually over time, without being swamped in bogus type errors from the start.

We haven't publicized it to-date, but all of this work has been happening in the open, in the Ruff repository.

All driven by a uniquely great team: @carljm, @AlexWaygood, @sharkdp86, @MichaReiser, @DhruvManilawala, @ibraheemdev, @dcreager.

I'm learning so much from them.

Warning: this project is not ready for real-world user testing, and certainly not for production use (yet). The core architecture is there, but we're still lacking support for some critical features.

Right now, I'd only recommend trying it out if you're looking to contribute.

For now, we're working towards an initial alpha release. When it's ready, I'll make sure you know :)

From helping other projects have run across a fundamental issue which web searches have not given appropriate answers.

What should go in a tarball and what should not?

Is it only the build files, python code, and package data and nothing else?

Should it include tests/ folder?

Should it include development and configuration files?

Have seven published packages which include almost all the files and folders. Including:

.gitignore,

.gitattributes,

.github folder tree,

docs/,

tests/,

Makefile,

all config files,

all tox files,

pre-commit config file

My thinking is that the tarball should have everything needed to maintain the package, but this belief has been challenged. That the tarball is not appropriate for that.

Thoughts?

via https://bsky.app/profile/pyladies-bot.bsky.social/post/3lgkepjv6362w

Read my latest article Speed up workflow with this Python Toolkit | 2025 |.

https://medium.com/gitconnected/speed-up-workflow-with-this-python-toolkit-2025-04f7c8526022

@medium @pythonclcoding @python @pythonclcoding #python #Programming #CodingTips

Hello!

I recently published a new version of my Understanding Python re(gex)? ebook.

This book will help you learn Python Regular Expressions step-by-step from beginner to advanced levels with hundreds of examples and exercises. In addition to the standard library re, the third-party regex module is also covered in this book.

Release offers

To celebrate the new release, you can download the PDF/EPUB versions for free till 31-Jan-2025:

• Leanpub
• Gumroad

Interactive TUI app

I wrote a TUI app to help you solve exercises from this book interactively. See PyRegexExercises repo for installation steps and app_guide.md for instructions on using this app.

See my blog post Python regex cheatsheet for a quick reference.

Web version and GitHub repo

You can read the book online here: https://learnbyexample.github.io/py_regular_expressions/

Visit https://github.com/learnbyexample/py_regular_expressions for markdown source, example files, exercise solutions, sample chapters and other details related to the book.

Feedback and Errata

I would highly appreciate it if you'd let me know how you felt about this book. It could be anything from a simple thank you, rating/review, pointing out a typo, mistakes in code snippets, which aspects of the book worked for you (or didn't!) and so on. Reader feedback is essential and especially so for self-published authors.

Happy learning :)

PEP 735 what is it's goal? Does it solve our dependency hell issue?

A deep dive and out comes this limitation

The mutual compatibility of Dependency Groups is not guaranteed.

-- https://peps.python.org/pep-0735/#lockfile-generation

Huh?! Why not?

mutual compatibility or go pound sand!

pip install -r requirements/dev.lock
pip install -r requirements/kit.lock -r requirements/manage.lock

The above code, purposefully, does not afford pip a fighting chance. If there are incompatibilities, it'll come out when trying randomized combinations.

Without a means to test for and guarantee mutual compatibility, end users will always find themselves in dependency hell.

Any combination of requirement files (or dependency groups), intended for the same venv, MUST always work!

What if this is scaled further, instead of one package, a chain of packages?!