Skip to main content

Not so fast

Python requirements files
Python package upgrade script

Don't know how to begin or what to say, but feel like saying something about a few Python development issues.

as hosts evolved from actual/virtual machines to containers, server deployment adapted accordingly. hosts were de facto containers because they had service interfaces, but deployment via systemd/upstart was unusual. i know supervisord was also used.

virtual environments became popular, because of host-server and server-server dependency conflicts. i avoided this style of virtualization by segregating servers and/or letting some servers govern the dependencies of others.

needless to say, containers and machines are quite different. when a container is server-specific, a virtual environment has no value.

thus, i install Python packages globally unless i'm forced to do otherwise.

The need for speed

Astral builds extremely fast tools to make the Python ecosystem more productive. (how do we measure ecosystem productivity?)

i like Ruff, because using Flake8 and isort requires slightly more effort. Ruff's speed is a nice feature, but it helps only when i make a stupid mistake, e.g. leave trailing whitespace. normally, i have to wait for mypy and the tests themselves. i often walk away.

in other words, the need for speed is more imaginary than real.

Dependency management

on the other hand, i dislike uv. if i wanted to build a virtual environment in a container, i would use a specialized tool for that purpose. preferring monolithic applications is weird.

most developers needn't create/update their environments that often. ignoring automated deployments, once per day/week might be sufficient. furthermore, even continuous deployment needn't be extremely fast.

like most applications, my server uses third-party packages. i install/upgrade them with pip, because it is the standard tool. (gotta love people who say they like standards while recommending deviation :-)

some packages should be upgraded immediately, e.g. ones that generate documentation. in general, immediate upgrades cause test failures about once a year. precise dependency specifications are essential, but postponing upgrades is more fearful than prudent. who hasn't resolved an issue by upgrading?

as it happens, i have mypy pinned to a version that's four months old because newer versions complain about stdlib code. depending on a package that's going through a rough patch is a classic dependency management scenario. a package manager should let me specify the pinned version and the latest bad version so a new release can trigger an upgrade. pip does not do this; this limitation is a bigger issue than its performance.

dependency conflicts are harder to resolve. we should review release notes to discover an optimal package combination. thus, a good package manager identifies the conflict, recommends solutions, and provides links to release notes.

in short, there are package manager issues, but focusing on performance seems misguided.

Labels:

Comments

Post a Comment

Popular posts from this blog

Improper english

Before retirement ended my last spell of unemployment, i wondered if the timing of that dismissal was ideal. one month earlier or later might have been better? improving a server log was my last assignment. like many other companies, their senior management believed in their culture, technology, and tools. like other well-funded companies, they used Splunk and wanted to use JSON format. nobody reviewed the pull request that would have established a baseline for my work. their Splunk dashboard code was not versioned. Overcommunicating JSON can be ideal, and creating a data structure to discover if a log entry describes an error is easy and reasonably fast, but computers find strings very quickly. a faster algorithm uses less electricity; computer activity is human activity. ...
Post a Comment
Read more

Deliberate logging

While diagnosing an error, it's not unusual to discover that the application log does not contain relevant information while also being overly verbose. DEBUG-level entries can be cryptic, and maintainers often insist that their applications emit them in production environments. the universal acceptance of low quality logs is a management failure. Holistic development a software development protocol should synergize best practices, but we should run away whenever someone claims that success depends on a protocol's complete implementation. incremental development of software is common, as is reusing large frameworks. the development process can mature similarly. Holistic Development is a protocol i should describe someday, but piecemeal presentation makes sense because partial implementation is help...
Post a Comment
Read more

Sphinx supplement

Once upon a time, i was in a team led by a developer who was devoted to introducing modern standards. he didn't have much experience, so i think this devotion was essentially a cloaking device. though we didn't generate documentation, most pull requests elicited a request for a docstring change. my first post about Holistic Development focused on logging . this one is about generated documentation. though software developers habitually read code, generated documentation can become their primary source of information because it's easier to read. it also assures product owners that features are addressed, and that the design is orderly. Documentation review a docstring is just a comment until documentation is generated. at that point, evaluation of docstring quality should be based on the generate...
Post a Comment
Read more