Would it be possible to create our own packages and use them locally only, without publishing it anywhere, to use it as a way of sharing the same assets throughout multiple projects?
Hi @print_helloworld ,
This is a feature that we want to ship in future release of the Package Manager.
Regards,
Pascal
That’s good to know
Is there an eta for an early release? Would love to use this in my projects.
This feature will be fully available and supported in 2018.2 through an update of the Package Manager UI and proper exposure of the package content in the project browser. I don’t know when this new Package Manager UI version will be available but it should be in the coming days/weeks. You can try the beta today and test part of the feature (see below). This new version of the Package Manager UI will be shipped with Unity 2018.3.
So if you want to test this feature in the 2018.2 beta, you can drop a package manifest (package.json
)inside a sub-folder of your project’s Packages/
folder. The package manifest must have the name
and version
attribute defined.
For example, if you create this file at /Packages/my_package/package.json
with this content:
{
"name": "my_package",
"version": "0.0.1"
}
… you will see the package my_package
appear in the project browser under the Packages
root.
We call this process, embedding a package in your project.
Alternatively, you can use the local package feature. With this feature, you can a add package located anywhere on your system through the file:
scheme.
To try it out, in the dependencies
section of the project manifest (/Packages/manifest.json
, add a local package dependency like this:
"dependencies": {
"my_package": "file:/my_package/folder/"
}
Note: This is possible in 2018.1, but we don’t promote these features because the Package Manager UI and Unity’s project browser are not built for it.
Hope it helps!
Pascal
So I’ve tried with 2018.1.0f2, and you the manifest.json doesn’t seem to support the "name": "path"
format. I’ve tried adding a local folder as a registry with the "file:///C:/path/folder/etc"
format, but this didn’t work either.
Failed to resolve packages: Registry url is invalid. Expected http or https protocol
I’ll be trying out with 2018.2 now.
Edit: Giving the dependency file an entry with the path in an http format works, before I was trying out with a local file format, which is what didn’t work. So I think an overload clarification would be nice in the documentation.
Edit 2: I didnt notice your comment on the file:
format, my bad.
There is also no author property for the packages so there is no way to change the author name that is shown in the UI.
I’m sorry. I may not have been clear. We don’t support setting a registry to a local folder.
See my example above. You can add local packages to your project through the dependencies
attribute. It should work in 2018.1. I suggest you wait for the full feature to be exposed through the UI.
Regards,
Pascal
Just a heads up on this.
I’ve run into a problem with using “file:” on mac in 2018.2.0b5.
The following paths are not valid and cause a “version schema file
is not valid” error:
"com.cratesmith.codebase" :"file:local/cratesmith.codebase",
"com.cratesmith.codebase" :"file:./local/cratesmith.codebase",
However, moving the packages and using the following path works
"com.cratesmith.codebase" :"file:cratesmith.codebase"
The same project works fine in windows on 2018.2.0b3 with all these variations.
Hi @Cratesmith ,
In you to example, where was the package located in your system? If you set this in project manifest:
"com.cratesmith.codebase" :"file:local/cratesmith.codebase"
or
"com.cratesmith.codebase" :"file:./local/cratesmith.codebase"
The package manager will look for this package under your project path at this location:
<your project>/Packages/local/cratesmith.codbase
Was this the location of your package on your system?
For you info, if you move your package at this location:
<your project>/Packages/cratesmith.codbase
You are not requiring to add an explicit reference file:
in the project manifest. It is automatically grabbed by the package manager. We call this embedding a package.
We will try to repeat on our end your issue. Thanks for reporting!
Pascal
I got the packages to work on my end.
You suggested to place the package contents in a folder relative to the project, however, I placed them in a different directory altogether and it worked perfectly fine.
{
"dependencies": {
"pop.canvas": "file:\\Users\\user\\Documents\\GitHub\\shared\\Pop.Canvas"
}
}
In the Pop.Canvas folder there is a package.json file with these contents
{
"name": "pop.canvas",
"displayName": "Pop.Canvas",
"version": "0.5.2",
"description": ""
}
I remember setting the file path to something like file:///C:/Users/user/Documents/GitHub/shared/Pop.Canvas
and it auto reformatted to what it is now.
Maybe this can help you even though you’re on a different os, @Cratesmith .
Cheers.
Hey @okcompute_unity
In both cases I kept the packages in <project>/Packages/local/cratesmith.codebase
and <project>/Packages/cratesmith.codebase
Will try without the file: prefix to see if it works.
I’m working on a multiplayer project so I have two copies of unity running on two projects where the secondary project’s Assets/ProjectSettings/Packages folders are symbolic links to the same folders from the main project. (It’s a much better workflow than doing builds to test multiplayer).
I’m using the local folder to get around another issue. Unity won’t load manifest.json if it’s loaded in a symlinked Packages folder.
The workaround I’ve found is that it will load manifest.json if it itself is a file symlink. This allows me to then symlink the local folder instead of the packages folder to have my secondary project work.
Note: I was having the issues on mac in the primary project so I’m pretty sure the package path issues I was having on mac aren’t related to this symlink setup.
We are running Unity 2018.1.1f1 and just tried the local package scheme. It seems to work fine, until you get into assembly definition files (shortened asmdefs).
Our local package: FooUtils has a root asmdef, an editor asmdef and a editor-test asmdef. In our BarProject we use the filepath dependency to import FooUtils. If BarProject has no asmdefs of its own, then I can not reach any code in the FooUtils editor or editor-tests asmdefs. If I add an asmdef to BarProject, then I can not access ANY code from FooUtils because the asmdefs for FooUtils does not show up in the selector for BarProject.
I would like to reach the FooUtils editor asmdefs to use base-classes for editor windows and unit-tests from there.
Is this issue considered and/or resolved for 2018.2?
You also cant access the mono behaviors that belong to a package in editor (add component menu). My workaround currently is to inherit from the class explicitly and use that class instead.
@Yacuzo I’ve done this without any problems.
It sounds like you may have not defined dependencies between the asdmdef files?
The only one that I’ve found that doesn’t work is that test asmdefs in packages are not found by the test runner.
@Cratesmith The dropdown for the asmdef dependencies is empty. It does not show any asmdefs from packages. Note that this is for 2018.1. I was just wondering whether this 2018.1-problem was corrected for 2018.2.
@Yacuzo It’s entirely possible. I had to switch off 2018.1 for other issues on my project.
What I’ve had to do in 2018.2 is copy/symlink my test folders from packages into the Assets folder as they don’t get scanned by the test runner.
@okcompute_unity Is the test runner only scanning the Assets folder by design? Or is this a bug? I can see both being valid ways for it to work, but it would be good to get some clarity on what the plan is.
@okcompute_unity Also I’ve done a bit more digging with my mac problem.
The problem doesn’t seem to be with the project’s manifest.json. Rather it’s that those packages can’t find their own dependencies if they’re not in the Packages folder.
For example the following package:
{
"name": "com.cratesmith.codebase",
"displayName": "Cratesmith Full Codebase",
"version": "0.0.1",
"unity": "2018.1",
"description": "Cratesmith full codebase",
"keywords": [
"cratesmith",
"unity"
],
"category": "Unity",
"dependencies": {
"com.cratesmith.core": "file:../cratesmith.core",
"com.cratesmith.actors": "file:../cratesmith.actors",
"com.cratesmith.effects": "file:../cratesmith.effects",
"com.cratesmith.idtypes": "file:../cratesmith.idtypes",
"com.cratesmith.serializedtypefactory": "file:../cratesmith.serializedtypefactory",
"com.cratesmith.settings": "file:../cratesmith.settings",
"com.cratesmith.statemachine": "file:../cratesmith.statemachine",
"com.cratesmith.sensors": "file:../cratesmith.sensors",
"com.cratesmith.scriptexecutionorder": "file:../cratesmith.scriptexecutionorder"
}
}
Works fine if all the packages are in the UnityProj/Packages folder. But if I move my packages to any other folder I get the following error for any dependencies they have.
@Cratesmith I dont think dependency parsing for local packages is supported yet. If you put all nested dependencies (ALL your packages that are used by other packages) into the projects manifest.json, then it all works fine.
Regarding reaching code in package asmdefs: I can add the asmdef references manually by text-editing the projects local asmdef, then I’m able to use code from packages. It’s tedious, but it works.
@Createssmith, we don’t support local dependencies within a package. This type of dependency is only supported in the project manifest (/Packages/manifest.json).