[yunzheng]

When you currently use a --pre package of the dissect meta package it will still use the pinned version of the latest stable release. We should relax the dependency pins after the release so a new dev package is created for the dissect meta package.

This allows users to use the dissect meta package when testing without referencing dissect.target all the time (which is where main development takes place, but not always).

After this is merged we can then just call:

uv run --pre --with dissect target-shell

Also, i've chosen version ranges for now, but this means that dissect.cstruct is pinned to <5, while dissect.cstruct is preparing for a 5.0 release. This means it will not install the latest development version of dissect.cstruct, but still stay at the development versions of 4.x.

Feedback is appreciated if we should drop the version ranges of the dependencies all together.

Closes #110

[Copilot]

🟡 Changes recommended

The chosen upper bounds (e.g. <5, <4) still allow next-major prereleases like 5.0.devN/4.0.devN under PEP 440 when --pre is used, which can defeat the “exclude breaking next-major dev versions” intent.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

This PR updates the dissect meta-package dependency specifiers so that, after the 3.22 release, development installs (e.g. uv run --pre --with dissect ...) can resolve to newer prerelease builds of the component modules instead of being locked to the last stable pins.

Changes:

• Replace exact == pins for Dissect modules with version ranges (>= last_release, < next_major) in pyproject.toml.
• Keep lower bounds anchored to the 3.22 release versions to prevent the resolver from selecting older module releases.

File summaries

File	Description
pyproject.toml	Switch Dissect module dependencies from exact pins to bounded ranges to enable prerelease resolution on main.

Review details

Suppressed comments (1)

pyproject.toml:52

• Similarly, <4 will still allow 4.0.devN when --pre is used, which undermines the intent of preventing next-major breaking changes from being pulled in during prerelease installs. Consider using <4.0a0 if you want to exclude all 4.x prereleases while still allowing 3.x dev builds.

    "dissect.target[full]>=3.25.1,<4",

• Files reviewed: 1/1 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[twiggler]

Hi,

I think a downside of this approach is that it adds commit noise.

Moreover, with the monorepo approach, there are no more dev packages because the workspace has the live source code for all internal dependencies.
Instead you can clone and do uv run or use uv tool install git+https: (should work but untested)

[yunzheng]

Hi,

I think a downside of this approach is that it adds commit noise.

Moreover, with the monorepo approach, there are no more dev packages because the workspace has the live source code for all internal dependencies. Instead you can clone and do uv run or use uv tool install git+https: (should work but untested)

I agree that after a monorepo approach this will definitely add commit noise after each release. But currently (before monorepo era) this should be minimal as we don't release often.

Also, I think using uv run or uv tool install directly on the git+https repo will also not work immediately, as the versions will still be pinned in the meta package for stable releases, or can this be solved differently?

My goal is mainly to make it easy as possible to run the latest development version for users (and developers) without installing too many dependencies (some require pre-built wheels for example).

Wen monorepo? :)

[Schamper]

I think --pre should be the canonical and blessed path to install pre-release versions. Installing through the URL is suboptimal. I don't think the commit noise would be too bad.

with the monorepo approach, there are no more dev packages

We won't publish dev packages to PyPI anymore? I didn't realize that, that's a regression in my eyes. The dev packages are on the one hand for our own development purposes, but also serve as user-facing access to pre-release packages.

[yunzheng]

Monorepo discussions aside, do we see any issues merging this? It will be a big quality of life improvement for people who just want to run the latest development version

[Schamper]

I don't see any issue with this.

[yunzheng]

I don't see any issue with this.

Can you approve review?