You can pretty much use it as a drop-in replacement for anything built on top of DINOv2. E.g. if you want to fine-tune a segmentation model you can use EoMT[0] which uses DINOv2 as backbone and replace the backbone with DINOv3. If you just want to run it you can give LightlyTrain a spin [1]. There should also be support in the original EoMT repo soon. The methods in the DINOv3 paper focus on frozen backbones which are usually faster to train but might have lower performance than full fine-tuning.
Nonocycle is a small tool I developed to detect potential circular imports before they are introduced into a codebase. It achieves this by enforcing a strict separation of concerns between sub-packages.
In my experience, circular imports are often not introduced in a single PR but build up over time. Developer A adds a dependency between modules X and Y. Developer B adds a dependency between Y and Z. Developer C wants to add more code, encounters a circular import error, and ends up in refactoring hell. This is especially problematic in larger projects where not all contributors are aware of how different modules depend on each other.
Most discussions about circular imports focus on how to fix them, while much less attention is paid to prevention. The common advice is to "split code into well-separated modules," which is of course correct but high-level and difficult to enforce. I created nonocycle because I couldn't find another tool that ensures modules remain well separated.
> This is a weekend project and is by no means production-ready. The heavy lifting is done by the excellent pydeps and networkx libraries. Please let me know if there are any other tools in the space :)
[0]: https://github.com/tue-mps/eomt [1]: https://docs.lightly.ai/train/stable/semantic_segmentation.h...