1

When developing a managed (namespaced) package in a scratch org we'd also like to install another package to help fully test it's behaviour.

This other package actually requires the one in development and at present it's installation is failing since it thinks its dependency (the package in dev in the scratch org) isn't installed.

I get this issue when installing through CLI and GUI.

enter image description here

Improve this question
3
  • So your scratch org is populated with unpackaged metadata? Can you perform your testing in a scratch org with a managed beta installed, and does that help?
    – David Reed ♦
    Jun 5, 2019 at 12:14
  • Ah yes we could (and do) do this testing in a scratch org with a packaged version, but that takes extra time and it would be nice to be able to have full visibility and modify code as we're still essentially in development stage (of additional features)
    – Todd Halfpenny
    Jun 5, 2019 at 12:32
  • Use 2GMP, I have posted my answer. @ToddHalfpenny Not sure if this is still relevant for you
    – Patlatus
    Sep 20, 2021 at 12:14

2 Answers 2

Reset to default
1

It sounds like you can't install Package B in Package A org because Package B depends on release 1.164 of Package A. That being the case, I'm guessing in the packaging org of Package B, you had v1.164 Package A installed when you created a release of Package B?

If that is the case, I'm not sure you're going to get out of that without releasing the dependency on Package A, in Package B.

Dependencies are likely caused as a result of referencing code or objects from Package A, in Package B. You could potentially release those dependencies by using dynamic SOQL/DML and potentially utilising the Callable interface if you're calling APIs.

Could you save yourself the time and install both into another Test org?

Improve this answer
1
  • Yes this is our assumption... though I'm hoping there's a way around this as when developing a package in a namespaced scratch org I would have hoped that all dependencies were actually in place. We'd like to not have to do this post-packaging of Package A, as we're in essence still in dev mode, and doing this would mean extra time and process.
    – Todd Halfpenny
    Jun 5, 2019 at 12:35
0

Have you tried to convert both of the packages into 2GMP form?

This way, you could deploy the unmanaged code for both packages in the same scratch org

{
    "packageDirectories": [
        {
            "path": "force-app",
            "default": true,
            "package": "Baseline",
            "versionName": "0.0.0",
            "versionNumber": "0.0.0.NEXT",
            "ancestorId": "04tBase000Line0AAA"
        },
        {
            "path": "dependent",
            "package": "Dependent",
            "versionName": "0.0.0",
            "versionNumber": "0.0.0.NEXT",
            "dependencies": [
                {
                    "package": "Baseline",
                    "versionNumber": "0.0.0.LATEST"
                }
            ],
            "default": false
        }
    ],
    "namespace": "Namespace",
    "sfdcLoginUrl": "https://login.salesforce.com",
    "sourceApiVersion": "52.0",
    "packageAliases": {
        "Baseline": "0HoBase0000Line0AAA",
        "Dependent": "0HoDEPENDENT000AAA",
        "Dependent@0.0.0-1": "04tDEPENDENT000AAA",
        "Baseline@0.0.0-1": "04tBase0000LineAAA",
    }
}
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .