spine-runtimes
spine-runtimes copied to clipboard
EsotericSoftware
[unity] Unity scoped package registry
Hey guys,
first of all nice that you moved your stuff already into UPM packages. But it would be also awesome, if you could move your stuff into a scoped package registry, which contains than the unity-spine-core but also all the modules. So with that we could use Spine and the different modules and versions completely based on your git repository, instead of downloading the package, copying it either in the project or somewhere else to add it as a local repo.
Cheers!
I already submitted it to OpenUPM, so there's no need to set up your own registry. The only thing holding it back is #1683 because spine-csharp has to be manually embedded into spine-unity. Maybe you can add symlinks to each file?
Hi, I create a temp project that fill the spine-csharp folder. With that, I was able to create another project in OpenUPM that uses this new repository. And it worked. However, I think this is not necessary if the csharp folder is already filled in the official project.
I'm going to destroy today the repository that I have created because I don't know if I can legally do that. I already destroyed the repositories
In general we prefer to maintain and publish our Spine Runtimes ourselves. The problem with 3rd parties publishing our Spine Runtimes separately is that we have no control over the 3rd party published artifacts. This has always led to outdated 3rd party packages. Our users then turn to us and ask for support, which we can't give, as we lack the necessary control. It is for this reason, that we ask that you maybe reconsider publishing our Spine Runtimes like this. We see the value in what you are trying to do, but we'd prefer to do it ourselves.
In case of OpenUPM, I already see a duplicate entry of the spine-unity runtime here and here, one listed under the MIT license. I'm afraid that does not work. You must retain our licenses on all our code and assets. Here are the two licenses applying to the code:
http://esotericsoftware.com/spine-runtimes-license http://esotericsoftware.com/spine-editor-license#s2
Our Spine Runtimes are not Open Source under the OSI definition, but source available. Users of the Spine Runtimes must have a valid Spine Editor license. [Edit:] Thanks for destroying the packages with incorrect licensing information @icaro56 !
Regarding the dependency to spine-csharp and symlinks: we do not want to commit symlinks to another location of the same git repository. It would rather be a separate spine-csharp package and added as dependency to the spine-unity package.
How can I use the spine-csharp as a dependency? It doesn't have the package.json.
It is not yet setup as a package. Which is why this ticket exists and is not yet set to done.
Oh yes, I'll be waiting. I apologize for my ignorance about all of this. Thank you.
No problem, thanks for acting so quickly with deleting the package entries (I see the pull request on OpenUPM, so I assume it will be updated soon).
It is because I really need this functionality, otherwise my game project will be too big for having to add spine packages locally in repository. The OpenUPM project will give you great powers. It is much more practical to use a package made for unity.
Please note that in the meantime you have the option to not include the Spine Examples directory, without it your repository will just contain a few hundred additional kilobytes of code files.
@icaro56 For now, I would just add the runtime into your repository directly, then switch to OpenUPM packages when they're ready. Not ideal, but good enough for now.
@HaraldCsaszar Two things. First:
The problem with 3rd parties publishing our Spine Runtimes separately is that we have no control over the 3rd party published artifacts. This has always led to outdated 3rd party packages.
I agree, you're within your rights to be concerned about this. OpenUPM in particular, however, updates packages automatically as described here. It checks the repository for newly-pushed semver tags; once the package is set up properly the first time, everything else is pretty fire-and-forget. Will that be sufficient?
Second:
Regarding the dependency to spine-csharp and symlinks: we do not want to commit symlinks to another location of the same git repository. It would rather be a separate spine-csharp package and added as dependency to the spine-unity package.
If you provide spine-csharp and spine-unity as separate UPM packages (either with your own registry or with OpenUPM), please remember to include .meta files for both; Unity does not create .meta files for installed UPM packages, as they're stored in read-only directories. Files without .meta data in UPM packages are not imported.
Thanks @JesseTG and @icaro56 for promoting OpenUPM.
Hi @HaraldCsaszar,
I'm running OpenUPM, a UPM registry serving selective UPM packages with automatic build pipelines. It monitors new GIt tags and releases UPM packages based on it. I'm also a Spine user. I'm appreciated that you make the source available until your license.
Because OpenUPM is a low friction service, you're welcome to publish your packages to it, either with source code or compiled DLL. Even you'd like to set up your own UPM registry or using NPM, our CLI can still help slightly:
openupm --registry https://YOUR_UPM_SERVER add com.esotericsoftware.spine.spine-unity
You may notice that a few packages with version 3.8.0 have been published to OpenUPM, with license "Spine Runtimes License Agreement". However I checked the license section 2.2, it seems we DO NOT have the right to publish a UPM package based it.
2.2 Product Distribution. During and after the Term of this Agreement You may market, sell, publish, distribute, or otherwise make available the Spine Runtimes as integrated into Products, provided that:
(a) the Spine Runtimes License Agreement provided in Exhibit A is included in the documentation or other materials provided with each Product; and
(b) You had a valid Spine Editor license at the time the Spine Runtimes were integrated into each Product.
If this is true, I'm sorry for the mistake and will remove the package and block the namespace to prevent re-submitting in the future.
No, I should be the one apologizing for that; I should have read the license more thoroughly before deciding to submit it, but I didn't.
FYI: The below packages have been purged from the OpenUPM registry, and added to the blocked list to avoid the future submission.
com.esotericsoftware.spine.lwrp-shaders
com.esotericsoftware.spine.spine-unity-examples
com.esotericsoftware.spine.spine-unity
com.esotericsoftware.spine.timeline
com.esotericsoftware.spine.urp-shaders
But if you changed your mind (to allow 3rd party publishing your UPM packages), feel free to notify us here.
How is this progress? I'm not sure but there is documentation point to this repo Installing-Extension-UPM-Packages but I can't fine Packages folder in unity, only meta file of that folder left there
@Thaina The Packages directory is located directly in the project folder, on the same level as your Assets, ProjectSettings and Librarydirectories.
@Thaina The source directory is the Modules directory (renamed from Packages to Modules to prevent any problems), as mentioned here in the documentation, under Installation. Thanks for pointing out the leftover .meta file, it has just been removed.
Thank you very much, it make me confused but now I could be sure to move from my old packages folder to UPM
@HaraldCsaszar Remove Spine folder then Try to include Spine as UPM cause this error (and much more)
Library\PackageCache\com.esotericsoftware.spine.spine-unity@106250a6c5\Runtime\spine-unity\Asset Types\AtlasAssetBase.cs(42,19): error CS0246: The type or namespace name 'Atlas' could not be found (are you missing a using directive or an assembly reference?)
Seem like there was dependency on Spine-Csharp that was not made into package
@Thaina thanks for the info. The package.json file of spine-unity is (for now) intended for use from the unpacked unitypackage with the Spine\Runtime\spine-csharp directory containing the content of spine-csharp.
If you want to use it directly via git, typical usage for now is creating a symlink from <gitroot>/spine-unity/Assets/Spine/Runtime/spine-csharp/src to <gitroot>/spine-csharp/src. Of course you can also copy the content over, but then you cannot use git pull to pull the latest changes.
We know that this is a bit unfortunate, we will improve things in this regard as well when setting up the scoped package registry.
Thanks then. I would wait for your scoped registry. Hope it would be available soon
Remark: also requested on this forum thread: http://esotericsoftware.com/forum/Spine-Unity-UPM-ready-but-nonfunctional-out-of-the-box-14586
Re: Hosting the packages, there's also the possibility of using Github Packages as an organization level package registry to host these. Paired with Github Actions, publishing new versions automatically could be fairly painless.
Using Github Packages with Unity is at least unofficially a supported usecase, but does come with some caveats that would need to be documented for smooth user experience.
To be fair, self-hosting a package registry isn't very involving either and does avoid the pain points of trying to force Github Packages to play well with Unity.
Hello @HaraldCsaszar. Do you have any news on this topic? In 2020, many external libraries/services in our project have moved to UPM and it's becoming a standard in the Unity space. I will also be happy to see Spine fully support UPM.
You will receive any news automatically by subscribing to this topic and subscribing to the forum thread above. We will not secretly update anything, any git commits will be linked to this issue ticket.
Add this line
"com.esotericsoftware.spine.spine-unity": "https://github.com/EsotericSoftware/spine-runtimes.git?path=spine-unity/Assets/Spine",
into manifest.json still cause error
Library\PackageCache\com.esotericsoftware.spine.spine-unity@a8da830de2\Runtime\spine-unity\Components\SkeletonRenderer.cs(262,33): error CS0246: The type or namespace name 'Skeleton' could not be found (are you missing a using directive or an assembly reference?)
And another 200+ similar error