Develop against local-only packages without `../../` or absolute paths in dependencies

[owl-from-hogvarts]

Problem

I am developing set of library crates for personal use. I want to reuse them in several projects of mine. I do not want to publish the libraries or final projects anywhere to the internet or any even private servers as they are for my personal use only (university tasks).
I don't like to specify path dependencies as paths may look like: ../../../library-crates/project. So path dependencies are not an option for me!

Workspaces and other stuff is discussed in linked stackoverflow question

Proposed Solution

Allow adding locally developed unpublished crates to local-registry (that is source of type directory and local-registry) .

The approach is similar to maven which allows to mvn install package to local repository and later reuse it as regular dependency in other project without specifying obscure paths.

Npm supports similar workflow:

npm link --global # links package to global registry
npm link --global my-personal-library # links package from global registry to dependencies of another project

Notes

In context of this issue local means located on exact same machine, served ideally through filesystem. Some kind of daemon is also acceptable

Link to relevant stackoverflow question: https://stackoverflow.com/questions/78279201/how-to-add-local-package-to-local-registry-in-cargo

[epage]

Another potential way of dealing with this is the base paths proposal.

Renaming this to focus on the problem and not the solution.

[mamekoro]

I'm in favor of the built-in local registry feature.

There are issues with path dependency, such as the difficulty in pointing to a specific version and the hassle of updating settings when the path changes.

With a registry, it's possible to store multiple versions, and if it's a built-in local registry, it should have a default registry path (e.g., Maven's default is ~/.m2/repository), so the problem of path changes should not arise.

[epage]

@mamekoro have you looked at base paths proposal? In what ways would or wouldn't that meet your needs?

[mamekoro]

(The link is broken. The correct URL is https://github.com/rust-lang/rfcs/pull/3529)

It seems that the RFC does not address the use case of wanting to depend on a specific version of a local project.

When multiple local projects exist, and each needs a different version of the same local crate, path dependencies become difficult to manage. While using my-local-utils = { git = "file://path/to/local/crate", tag = "..." } is an option, specifying file paths makes migration cumbersome when the path changes.

If Cargo supports a built-in local registry similar to Maven's local repository, the versioning problem will be resolved, and there will be no need to set up a third-party registry.

The built-in local registry should have a default registry path. So, ideally, I would like to use the local registry located at the default path by simply writing registry = "local" (e.g., my-local-utils = { version = "1.0", registry = "local" }). This is similar to how mvn install automatically uses ~/.m2/repository as the local repository. Unless explicitly specified by the user, the default path is used.

I'm aware of cargo-local-registry, but it does not support local publishing.

I think the RFC is useful and can coexist with local registries.

[epage]

It seems that the RFC does not address the use case of wanting to depend on a specific version of a local project.

I believe the versioning would be handled by what you configure the base path to point to. Not entirely sure what the concern is here.

If Cargo supports a built-in local registry similar to Maven's local repository, the versioning problem will be resolved, and there will be no need to set up a third-party registry.

What does Maven do when you try to publish with an existing version?

An inherent assumption in Cargo is that the registry is immutable but I would expect most use cases for a local registry would including editing without wanting to update the version on every change.

[mamekoro]

I believe the versioning would be handled by what you configure the base path to point to.

Every time a new version is released, do we need to create a new directory to store the new version of the project, copy the source files there, and change the base path to point to it?

That sounds like the user is manually performing tasks that should be handled by a registry.

What does Maven do when you try to publish with an existing version?

mvn install overwrites the existing artifacts, but I don't think Cargo should do the same if it has a policy that the registry is immutable (append-only?).

I would expect most use cases for a local registry would including editing without wanting to update the version on every change.

It depends on each programmer's development policy. I don't change the version for every single change, but I do change it for each release.

Once a local project is complete and stable, I want to keep it in a state where it compiles successfully.

When local project X depends on local project Y using path dependencies, if Y's code gets a breaking change, X will no longer compile. If I later want to add new features to X and resume its development, I'll find it no longer compiles and must start by investigating the cause.

Publishing past versions of Y to a local registry and configuring X to depend on the version prevents this problem.

[epage]

So you have versioned release of the packages that you want to point to, and not the source.

In that case, what is your reason for not publishing to a registry?

Its unclear but I assumed @owl-from-hogvarts is wanting an easy way to connect projects in their current state and I presumed this meant that they were unversioned. In one company's case that I'm aware of, there is no versioning outside of git itself and so the immutable nature of registry entries didn't work for them. So I'm looking to better understand this middle ground position you are in which can help us better develop to your situation and get a better understanding of how representative it is.