The upcoming pip install --only-deps feature is expected in pip 26.2, and it matters because a lot of Python backend projects are applications, not installable libraries.
Think:
FastAPI services
Django backends
internal scripts
data jobs
REST APIs
worker services
AI product backends
In those cases, teams often want to install dependencies from pyproject.toml without installing the application package itself.
Historically, this has led to workarounds, dependency extraction scripts, Docker hacks, requirements file duplication, and general spiritual damage.
Now pip is expected to make that workflow native.
That may sound small. It is not.
For production Python teams, dependency management is part of shipping. And in hiring, the engineers who understand packaging, Docker layers, dependency resolution, and deployment hygiene tend to be the ones who can keep systems boring in production.
Boring in production is good. Exciting in production is usually a meeting with incident notes.
Why dependency-only installs matter
A lot of Python projects are not designed to be installed as reusable packages.
They are applications.
But modern Python dependency declarations increasingly live in pyproject.toml. That creates an awkward question:
How do you install only the runtime dependencies for the application without installing the application itself?
This matters in:
Docker image builds
CI environments
test runners
deployment scripts
build pipelines
separated app and dependency layers
internal service templates
If your build process installs the whole project too early, you can hurt caching, add unnecessary steps, and make deployments harder to reason about.
The new --only-deps direction makes the intended workflow clearer:
Install the dependencies.
Then copy or run the app separately.
Do not pretend every backend service is a library package.
That clarity is overdue.
The Docker angle
This is where the change becomes very practical.
A common Docker pattern is:
Copy dependency files
Install dependencies
Copy application code
Run the service
Why?
Because Docker caching is useful. If dependencies do not change, you do not want to reinstall the world every time one route handler changes.
A cleaner future pattern could look like:
COPY pyproject.toml .
RUN pip install --only-deps .
COPY . .
CMD ["python", "-m", "app"]
That is simplified, and teams will still need to handle lockfiles, constraints, environment markers, private indexes, and build dependencies properly.
But the principle is important:
Dependency installation should be separate from application code whenever possible.
That makes builds faster, cleaner, and easier to debug.
pip and uv are converging on practical application workflows
This is also interesting because uv already supports a similar workflow with uv sync --no-install-project.
That tells us something bigger.
Python tooling is catching up with how teams actually deploy applications.
For years, the packaging ecosystem was heavily shaped around libraries and distribution. That still matters, but modern teams are also shipping:
services
agents
internal platforms
APIs
scheduled jobs
workers
data pipelines
AI products
Those projects need packaging workflows that fit application deployment, not just library publication.
The future Python backend stack increasingly looks like:
pyproject.tomlas the centre of project metadatalockfiles or constraints for reproducibility
dependency-only installs for cleaner builds
faster tools like
uvstricter CI around dependency changes
deliberate Docker layering
supply-chain awareness
clear separation between runtime, dev, and build dependencies
That is not glamorous. It is useful. A rare combination, frankly.
What Python engineers should take from this
If you are a Python developer looking for backend, AI product, or platform roles, packaging knowledge is more valuable than most people think.
You do not need to be a packaging maintainer.
But you should understand:
pyproject.tomlruntime vs dev dependencies
optional dependencies
lockfiles
Docker caching
dependency groups
private indexes
build dependencies vs runtime dependencies
environment reproducibility
how CI installs and tests your app
how your app is actually deployed
A strong interview answer is not:
“I use pip.”
A strong answer is:
“I separate dependency installation from app code in Docker builds, keep dependencies pinned or locked, avoid duplicating dependency declarations, and make CI install paths match production as closely as possible.”
That sounds like someone who has shipped things.
The hiring manager takeaway
If you are hiring Python backend engineers, packaging and deployment questions are underrated.
You can learn a lot by asking:
“How would you structure Docker builds for a FastAPI service?”
“How do you avoid reinstalling dependencies on every code change?”
“Where do you define runtime and development dependencies?”
“How do you stop dependency drift between local, CI, and production?”
“How would you handle private packages?”
“What is the difference between build dependencies and runtime dependencies?”
“How do you review dependency upgrades?”
“What happens when a package changes transitive dependencies unexpectedly?”
These questions reveal whether someone has only written Python locally or actually operated Python in production.
That distinction matters.
A lot.
A practical backend project upgrade candidates can do this week
If you want to stand out, take an existing Python project and add a production-ready packaging section.
Include:
pyproject.tomlseparated runtime and dev dependencies
uv.lockor another lockfile strategyDockerfile with cached dependency layer
CI workflow that installs dependencies the same way production does
Ruff
type checking
tests
README explaining the deployment flow
Add a README section called:
“How this project is deployed”
Cover:
how dependencies are installed
why runtime and dev dependencies are separated
how Docker caching works
how CI matches production
how dependency upgrades are reviewed
what could still go wrong
That section tells a hiring manager you understand the path from code to production.
Most portfolio projects stop at “run locally.”
Production-minded engineers explain how software gets shipped.
The bigger market point: AI startups still need boring backend discipline
The irony of AI hiring is that the companies moving fastest often need the most engineering discipline.
AI startups are hiring people who can ship quickly, but the best ones still need:
clean dependency management
clear deployment flows
reliable APIs
reproducible environments
strong observability
secure package handling
safe integration patterns
sensible CI
The model might be new. The backend problems are not.
If anything, AI products make these problems worse because teams are integrating more services, more tools, more agents, more APIs, and more experimentation.
That means strong product engineers need both speed and operational discipline.
The market is increasingly rewarding engineers who can build fast without making the platform fragile.
Quick Python watch from the last 7 days
pip 26.2 is expected to add --only-deps
The big one this week: pip 26.2 is expected to support installing only a project’s runtime dependencies without installing the project itself. This should simplify application-style Python deployments, especially where dependencies are declared in pyproject.toml.
FastAPI 0.140.0 landed on 24 July
FastAPI 0.140.0 included work to reduce memory usage in dependencies. If your team runs a large FastAPI estate or high-concurrency services, memory-related changes are worth tracking deliberately.
uv 0.11.31 and 0.11.32 continued packaging hardening
Recent uv releases included dependency-resolution performance work and package safety fixes, including rejecting source distributions and wheels with mismatched package names.
Python 3.15 beta 4 remains the release-readiness reminder
Python 3.15.0 beta 4 is the final planned beta. Teams maintaining libraries, internal packages, or deployment tooling should be testing now rather than acting surprised later, a beloved industry tradition.
Ruff 0.16.0 landed
Ruff continues to move quickly. If your CI depends on Ruff, pin intentionally and avoid surprise formatting or lint changes rolling into production branches by accident.
Job of the week
Senior and Staff Product Engineers
Profitable AI startup | New York | Series A | $250k to $300k base + equity + potential sign-on
A profitable AI startup in New York is hiring Senior and Staff-level Product Engineers.
They are Series A, backed by top VCs, and building in a high-growth AI market with serious commercial traction.
They are primarily looking for senior and staff product engineers, but are open to other exceptional engineers with evidence of very strong technical ability, ownership, and product judgement.
Package and setup
$250k to $300k base
Equity
Potential sign-on bonus
5 days per week onsite in New York
Profitable AI startup
Series A
Backed by top VCs
What they need
Senior or Staff-level engineering ability
Product-minded builders
Strong backend, full stack, or systems fundamentals
High agency and ownership
Ability to work close to users, product, and founders
Evidence of exceptional execution
Comfort moving quickly in an intense startup environment
This is a strong role for engineers who want high compensation, real ownership, and the chance to build inside a profitable AI company at Series A.
Outro
The most useful Python signal this week is simple: deployment details matter.
Dependency-only installs, Docker caching, pyproject.toml, lockfiles, CI consistency, and package safety might not look exciting, but they are exactly the kind of things that make production systems easier to operate.
Great Python engineers do not just write code.
They make the path from code to production cleaner, safer, and more predictable.
Open question for debate: what is the most underrated production skill for Python engineers: packaging, Docker, CI, observability, or dependency security?
Hiring? Contact
Josh Smith
Email: [email protected]
Phone: 01727 225 552