You cannot export a Package Manager package to a .unitypackage and expect this to import it as a Package Manager package in another project. Actually I’m surprised that this even works once!
.unitypackage is basically a ZIP file of the contents that you exported, it’s not a package that’s compatible with Package Manager
You would normally develop packages in this way:
create a package folder outside of the project’s folder
in the project, import in Package Manager via “add from disk”
develop the package
If you want to use the same package in another project, you’d also “import from disk” using the same folder. That way both projects reference the same package folder and changes to the package are instantly available in the other project.
Normally you’d also put that package folder under source control. This also gives you the option to clone the package multiple times, for cases where you specifically do NOT want the package to be updated all the time (like an already-released project).
I should probably mention that I am using the API through AssetDatabase.ExportPackage. I also tried using Hybrid Packages, but it gives same result. I’ve used this workflow for the past half year, and it’s worked perfectly except for the above.
Instantly? So if I change the local package in one project, and a month later open another project that also happens to use that same local package, then I am likely to see a bunch of red errors, right? Or how do people handle this? I’d much rather pull updates into projects explicitly.
But of course you may not want to update packages automatically, specifically in already completed/released projects. In that case you would need to use source control and clone the package repository multiple times, in the extreme case once per project. That way you have control over when and what changes of a package to pull into a specific project.
You could use branches for the package repository to cherry-pick changes into a specific branch which is checked out for a specific project, so you don’t accidentally pull the latest version.
The project itself has its own repo, as you would expect, and it uses many custom packages that also have their own repos. As I understand it, you would then register each of these packages as Submodules? That does complicate things a bit. Currently, while working on a project, I keep track of changes I do to custom packages, and before I move on to another project, I check if there is anything worth pushing to the designated custom package repos. Also not ideal, but at least it gives a sense of control.
In any case, I do not see why naming should be an issue when importing custom packages as unity packages. Did you try the above?
That’s one way to do it, but I’d rather check out (clone) the package repository to some other directory next to the project folder and choose “Import from Disk” in the Package Manager. That way the package is imported into your project but you have it in a separate repository, not as submodule.
The downside with this is when you work with a team. The package imported from disk is referenced by its absolute path, which may be different on each system. But you can manually edit manifest.json and change the path to a relative path. That way all team members only need to use a single root folder anywhere into which they check out both projects and packages.
I haven’t used that ExportPackage API.
But I have an idea: the extensions package has a dependency on the main project right? So maybe you could simply export only the extensions package and use the “include dependencies” option, that should create an exported unitypackage that contains both packages. But it may also try to include other dependencies that you don’t want to include.
Thanks for sharing this workflow, it may work in some cases.
I will have shader-includes in com.cec.something that will be referenced by other packages and assets in the Assets folder. At the moment, Shaders make references relative to the Packages folder, like Packages/com.cec.something/Runtime/CGIncludes/Noise.cginc. I think this is how Unity’s own packages does it. But will that also work if com.cec.something is located elsewhere, and imported using “Import from Disk”?
None of the three packages have dependencies. In the real case, yes they will have, but the issue occurs even without.
Is the Package Manager team really unaware of the hybrid unity/upm-package workflow? People are using it to ship upm packages via the Asset Store, myself included. Allegedly, Unity’s own Asset Store Tools is published in this way. In my view, hybrid packages is the best thing that happened since Unity began implementing upm. It’s just a single file, easy to distribute, and users just have to double-click it to unpack it where it needs to go. What is not to like?
I hope the Package Manager team will look into this odd naming issue.
Can’t comment for Unity on this but personally, I vaguely heard about this as there seems to be very little information / documentation on this besides this git project. I need to look into this myself though. But … currently I just find it way more convenient to develop everything under Assets/ rather than as packages. Since code is separated into folders and assembly definitions it’s not going to be much trouble to package that up sometime later.
As far as I know, the hybrid package feature is an experimental feature of the Asset Store Publishing tools and it’s not officially supported. (Yes, I realize the irony of the situation, where the package relying providing this unsupported feature is itself based on it.) That’s not to say you cannot use the feature, but there may be quirks and issues with it, or it may be removed at a later point in time.
That said, you did run into a genuine bug related to package paths, it seems. I suggest submitting a bug report with your repro steps, screenshot and files.
The fix just entered review for the latest development version and should be backported to 2021.3. Sorry it’s taking so long. As mentioned above, hybrid packages are not a supported feature, but we’re still taking care of it because the underlying bug can affect other systems than package import which relies on the same codepath and could run into similar, weird and possibly subtle bugs. Stay tuned!
Asset Store Tools actually have an option in their Upload Type dropdown now named “Local UPM Package”. Supported or not, your publishers are using this feature. We are using it because it is the only reliable way to declare dependencies to other packages. Checking scripting defines to validate the presence of other code has been an absolute mess, and Hybrid Packages provides an actual solution.
If Hybrid Packages is not a supported feature, what then are the prospects of supporting UPM packages directly on Asset Store, with no .unitypackage intermediate step? And … why would that be any better? You can send a unitypackage in an email, and just double-click to install. What is not to like?
@cecarlsen I completely understand your point of view. Hybrid packages definitely fill in a gap, but
their implementation is experimental (it’s gated by the UNITY_ASTOOLS_EXPERIMENTAL scripting symbol that clearly conveys this), which is why I’m saying they’re not supported. That doesn’t mean they don’t work, case in point the publishers relying on it.
Unfortunately, I’m not at liberty to discuss the specifics of upcoming features and associated timelines, but as you rightfully point out, the UPM format is currently the only way to declare dependencies on other packages… UPM packages, of course.
There are other benefits to using the (resolve/installation-based) UPM format instead of the (import-based) .unitypackage format:
Ease of upgrading/downgrading packages
Using the UPM solver to retrieve transitive dependencies
Controlling the size of your project by not having to track packages added as dependencies in the project itself (particularly important for projects tracked under VCS (Version Control Systems) that often have limits on repository size)
And of course, the benefits of automation made possible by using a package manager in the first place (reproducibility, stability, safety…)
Of course, sending packages by email and importing them by double-clicking likely serves some use cases, but that doesn’t scale very well to projects using hundreds or thousands of packages, or deep dependency graphs, not to mention that it doesn’t provide the level of safety that you can get when installation from a controlled source is managed by a system, with security checks in place to prevent malicious or illegal software distribution.
Do we have any progress about this feature? Actually did we ever have any announcement related to this feature at all? I wish to have some, at least explanation about roadmap of this feature. What it will be, what it could do and could not, and so on. For the future development preparation
