Import two identical modules at different addresses, without having two duplicate packages locally.

[cawthorne]

Discord user ID

No response

Describe your question in detail.

Been experimenting with this and seem to be hitting some walls with it.

If a module depends on 2 packages (they both have same code), can the single package can't be reused? Having to do this:

b::my_module::func_name(publisher);
c::my_module::func_name(publisher);

b and c are the same code, just different at objects.

My goal is to only have 1 package folder locally which I use to deploy to two distinct object addresses, and then link to and use in a third object address package.

My approaches so far are as follows.

On a local network spun up with:

aptos node run-local-testnet --with-faucet

I have a contract A which lives at object address 0xa which imports 2 contracts B and C, which live at object addresses 0xb, and 0xc respectively. There were all deployed by the same deployer account D.

Contracts B and C are identical at the source code level. I have experimented with naming the top level package name of C though.

So far I have been able to deploy contract B, then C, and then A successfully (in that order). But only if I locally duplicate the package folder for B and make a new C package, where I then change the package name just to make it different. I also then have to import 2 dependencies in package As Move.toml like so:

[dependencies]
AptosFramework = { git = "https://github.com/aptos-labs/aptos-core.git", rev = "ebdfadf4002c35e4095e23c6312eeb28beca8f72", subdir = "aptos-move/framework/aptos-framework" }
B = { local = "../B" }
C = { local = "../C" }

The project directory is:

project-root/
├── A/
│   ├── Move.toml   # imports B and C
│   └── sources/
├── B/
│   ├── Move.toml   # package name = "B"
│   └── sources/
└── C/
    ├── Move.toml   # almost identical sources, but package renamed = "C"
    └── sources/

The deploy for a works with the command:

  aptos move upgrade-object \
    --profile "$PUBLISHER_PROFILE" \
    --package-dir "$CONTRACTS_ROOT/a" \
    --object-address "$A_ADDR" \
    --address-name a \
    --named-addresses a="$A_ADDR",b="$B_ADDR",owner_a="$PUBLISHER_ADDR",c="$C_ADDR",owner_c="$PUBLISHER_ADDR" \
    --max-gas 50000 --assume-yes

This works, but requires a folder for B and C, even though they are basically the same thing.

I instead want to only have 1 package folder locally B. And then deploy B twice to two different addresses. Then link them both to A at contract As compile time.

I tried to first just see if I can get away with symlinking the source folder of B to C. But that runs into this kind of error when compiling contract A:

error: duplicate declaration, item, or annotation
  ┌─ /Users/username/Documents/aptos-contracts/contracts/scripts/a/../../a/../c/sources/my_module.move:2:18
  │
2 │ module b::my_module {
  │                  ^^^^^^^
  │                  │
  │                  Duplicate definition for module '(b=0x7A6BE6F90D62A06EF2C7B392ED4A3526626683F61DB03BA43E9A2794B126DC37)::my_module'
  │                  Module previously defined here, with '(b=0x7A6BE6F90D62A06EF2C7B392ED4A3526626683F61DB03BA43E9A2794B126DC37)::my_module'

So when it tries to deploy A, it checks both source codes and finds an naming collision error unfortunately.

I would hope there is an easy way to not let a naming collision be a blocker on two separate instances of the same contract.

Next I tried to see if I can delete the duplicate package folder C entirely, and so now I have just folders A and B.

And now the project directory is:

project-root/
├── A/
│   ├── Move.toml   # imports B twice, once as B and once as C
│   └── sources/
└── B/
    ├── Move.toml   # package name = "B"
    └── sources/

If I try this and then make contract As Move.toml contain something like this instead:

[dependencies]
AptosFramework = { git = "https://github.com/aptos-labs/aptos-core.git", rev = "ebdfadf4002c35e4095e23c6312eeb28beca8f72", subdir = "aptos-move/framework/aptos-framework" }
B = { local = "../B" }
C = { local = "../B" }

But I get the following error (I think importing the same package seems to be disallowed):

Compiling, may take a little while to download git dependencies...
{
  "Error": "Unexpected error: Unable to resolve packages for package 'B': While resolving dependency 'C' in package 'B': Name of dependency declared in package 'C' does not match dependency's package name 'B'"
}

If I instead try just:

[dependencies]
AptosFramework = { git = "https://github.com/aptos-labs/aptos-core.git", rev = "ebdfadf4002c35e4095e23c6312eeb28beca8f72", subdir = "aptos-move/framework/aptos-framework" }
B = { local = "../B" }

I get errors of the form:

error: no function named `my_module::func_name` found
    ┌─ /Users/username/Documents/aptos-contracts/contracts/scripts/a/../../a/sources/my_module.move:184:9
    │  
184 │ ╭         c::my_module::func_name(
185 │ │             publisher
186 │ │         );

Implying it doesn't know about C anymore. Even though C is now published on chain and A was given Cs address as a named-address. It should be able to pull C from onchain and match just based on my_module, in my opinion.

When I pull the contracts info with aptos account list --account 0x... I see the byte code, but I also see an empty source_map. "source_map": "0x". Unsure if this could be relevant or not though. It does seem to be aware what the package name of C was at compile time, as A gets deployed correctly if I use a different package name between B and C, and A doesn't deploy if I use the same package name between B and C.

I have also tried experimenting with using addr_subst in the dependency import, as well as hard coding addresses for both B and C. But so far it always seems to be able to tell the package name matched between how it is reference in A and the name used in C (whether it is just B re-deployed or a new C).

Anyway help would be greatly appreciated!

Thanks all.

What error, if any, are you getting?

No response

What have you tried or looked at? Or how can we reproduce the error?

No response

Which operating system are you using?

macOS

Which SDK or tool are you using? (if any)

Python SDK

Describe your environment or tooling in detail

$ aptos info
{
  "Result": {
    "build_branch": "",
    "build_cargo_version": "cargo 1.86.0",
    "build_clean_checkout": "true",
    "build_commit_hash": "",
    "build_is_release_build": "true",
    "build_os": "macos-aarch64",
    "build_pkg_version": "7.2.0",
    "build_profile_name": "cli",
    "build_rust_channel": "",
    "build_rust_version": "rustc 1.86.0 (05f9846f8 2025-03-31) (Homebrew)",
    "build_tag": "",
    "build_time": "2025-04-09 23:48:47 +00:00",
    "build_using_tokio_unstable": "true"
  }
}

[vgao1996]

Hi @cawthorne, thanks for bringing this up!

Currently our package system lacks these two critical features:

• Package renaming
  • When you try to force it (C = { local = "../B" }), you get an error complaining that the names mismatch
  • Ideally, we should extend it with syntax that allows renaming, such as C = { local = "../B", rename = "C" }
• Address renaming
  • There is the addr_subst syntax, but I investigated it a few days ago, and can confirm it's broken.

I know it's not ideal, but for now the best workaround is indeed to duplicate the source package.

I'm currently working on a new package system and it is part of the plan to get these properly supported, so stay tuned.

Also please let me know if you run into other package-related issues. I'd like to get those fixed as part of the revamp as well.

[cawthorne]

Hi @vgao1996 ! Thank you very much for your reply. It is very helpful.

I was struggling to find much documentation around this issue.

I am wondering if there any current work arounds.

Is this check also in the VM consensus layer? Even if the conflicting packages are deployed from entirely different machines/environments, will the VM still always refuse the upgrade based on the naming issues?

Is it possible to deploy without source code to avoid this issue? Then once the packages are linked add the source code?

Just to be clear there are two things we need to rename at the moment, and that is all of the package names in the source code e.g.
b::my_module::func_name becoming c::my_module::func_name.

And also the renaming of the package name in the Move.toml file, e.g.:

[package]
name = "PackageB"

[package]
name = "PackageC"

We can work with the folder duplication and package/named addresses renaming for now if that is the best option. I just want to be as clear as possible what our options are at present.

Thank you very much!