On Asset store new workflow

Unity Engine
,
1

Since there was a new experimental asset packaging system UNITY_ASTOOLS_EXPERIMENTAL I have found at "Failed to create folder structure" when importing custom package

I then try to experiment with it and there are many concern about

The most important part is. Even though the new system is was relocate package out of assets folder. The behaviour is unexpectedly difference from normal UPM system that, with the UPM the package ID will be inserted into manifest.json and pull the package into the PackageCache folder instead

With current implementation, the package just push itself into packages folder directly. And so it lose the benefit of making project be cleaned and readied to be distributed for collaboration

And the discrepancy in the behaviour itself is the problem. Actually I have several questions, which is the actual behaviour for the package? Should any and every package be stored in packagecache or the package folder directly? What is the big picture and goal of these 2 approach?

Also the uploading system was still being a unitypackage file anyway. Which make the changing, deleting, renaming, or refactor and relocate file harder to be tracked and maintain

In conclusion. The system was miserably conflicting with package manifest system. So much waste of UPM potential

I would like to suggest that unity asset store should allow git push as the another means of publishing. Unity server should have another package type, a git repo, and store the package in git system. Then register the package ID into unity’s own package registry

Maybe UPM should have 2 default registries. Unity’s official registry and My Asset’s registry. I means, unity server should setup the server to have our purchased and owned asset act like another scope registry and make it be second default registry to find package

And with this kind of asset, the Open in Unity button in asset store should just insert package ID into manifest. Also the asset store tool should have option to push git repo and specify semver for the commit

Another way is, instead of the need to upload the package, publisher portal should just allow us to put git url and link semver as a package. So that our package can be specify dependency by the semver like unity’s package. And we can put private git url with access token for unity server to cache and distribute

These system also serve the purpose of this request > Custom Package with Git Dependencies < So that we can make dependency to any package we wanted

1 Like
2

If I understand this correct, you complain that this system copies the package FROM Assets TO Packages?

If so, you are using it the opposite way as it was intended. You develop your package as a regular Unity Package Manager npm package, and the new Asset Store tools extract the package into Assets and then bundles it up for upload to the Unity Asset Store. This approach is called “hybrid package” and you’ll find more info on google.

You can set up a custom registry for yourself. This is what companies do to share packages internally.
There is also OpenUPM which hosts open source packages for Unity for free. And there are other ways to make this work with GitHub or NPJMS but the issue with these is that they do not resolve package dependencies. However, there are half a dozen of scripts and related packages on GitHub alone that provide this dependency resolution.

I would also love to have a way to unofficially distribute packages via a Unity endorsed registry. However, this could cannibalize on the Unity Asset Store, and Unity would be held responsible for any scam packages which would require screening like for the Asset Store, and then you’re looking at 6+ weeks of package approval …

3

You completely misunderstand

I am very satisfied that the new system will not pull package into assets folder, which it totally should be from the very start

But I am disappointed that it was still pull package into packages folder. While the actual UPM system just pull package into Library/PackageCache. And add only one line to manifest.json

I would suggest you please take a look at this link https://discussions.unity.com/t/732000

There would be multiple of my comments about the current system, especially the custom registry, that it is so much disappointed. It shouldn’t be that way and it cause friction to everything we do about UPM. And unity official also admitted that it was not flawless. There are roadmap and it was on their radar. But since 2020 there are still not fixed the issue

And the first thing you should do is understand it really was an issue and I trying to suggest the better here

4

In my opinion it was easy to avoid that

First, every package should be registry under organization ID. And package ID should be strictly constraint to be the same organization ID as the publisher

Which might required to be com.123456789.PackageName or something like this

Second, They can have the same review process for having the asset being published and discovered in asset store. But just allow every package to be registered in unity server

This is separate issue. Unity asset store will need to be verify for 6 weeks or anything to be allowed to sell and distribute with asset store. But to be discovered and resolved as dependency from UPM system, it should always be possible immediately and even it was not listed in assetstore yet

Actually it opposite, people should allowed to upload any submodule package, such as shaders and scripts, into a unity publisher’s server. Then that package can be referenced as dependency from other asset they sell in store. That would be ideal and that is the main use case I have right now. I have a repo package in github that I want to add as dependency of my asset I publish into the store. But the package dependency did not allowed git dependency. Or even another package in the store. Importing my own package in another project then give me this error

Package com.my.Package has invalid dependencies or related test packages:
com.my.AnotherPackage (dependency): Version 'https://github.com/my/Package.git' is invalid. Expected a 'SemVer'

And this is totally frustrating

5

It is not entirely true. Packages live in package cache if they are not changed in any way. You can move any package from the cache to the packages folder and change the content. Which means ANY package can live either in the package cache (immutable) or in the packages folder (mutable). This is an original feature of UPM (AFAIK), it was always this way and this is the official way to make packages mutable. Asset store assets by default mutable (otherwise they wouldn’t be backward compatible), so they have to go into the packages folder.

6

Right, one thing I forgot to mention but actually the most disappointed about the system is. We need to make a package.json and specify package ID

But then I have tried and it seem we still could not even make our package we published into assetstore being a dependency of another package in asset store (I am not 100% sure so sorry if I am wrong on this one)

7

You are right about we could manually moving package. But the point is, package should be immutable by default and mutable by optional

Package that being installed from new system of assetstore should also come as immutable, utilizing manifest.json, instead of invading into our project repo

Actually I also have been made a suggestion that UPM should have UI and API to let us specify which package we would like to be mutable

But in any case when we import package it should also add the info about the package into manifest.json and resolve the package in packagecache or packages folder based on option to be mutable or immutable

And in the recent version of unity we now have sophisticate asset variant system. Instead of modifying asset directly we should always make variant out of immutable asset

Also what I propose is the system for publishing new asset for newer version of unity that support UPM. Older asset that still use unitypackage file would not changed in anyway

8

That would require many assets to rewrite which would alienate a bunch of asset store creators who already aren’t happy by other recent changes and in dire state in terms of business. In theory I agree with you, in practice, I don’t.

Anyway, I would actually support a repo-based asset store any day. Maybe git, maybe Plastic-based, whatever works best for Unity.

9

Also what I propose is the system for publishing new asset for newer version of unity that support UPM. Older asset that still use unitypackage file would not changed in anyway

I should actually add that for older asset, I mean older system. People should still be allowed to publish asset with unitypackage in the same exact way we have did all along. My proposal should just be separate radio option in publisher portal

10

I’ve recently read these threads, not entirely though, but I was also looking for an easy way to get just two of my packages resolve their dependencies. I want them on github, and I want Package Manager to resolve the dependency. Could this be so hard?

Apparently not seeing all the scripted resolvers. But so far I’ve only read about them and they all seem to require from package developers to follow a certain set of rules that are just a bit too restrictive, or just don’t fly with me.

I’d love to have an open, really open, package manager registry. But one that isn’t hampered by the process provided by OpenUPM where you have to send pull requests and wait for hours, only to have to manually set up a registry scope for each and every package. I just want to specify OpenUPM as the registry and be able to discover all the packages.

However at this point, seeing how many crapshoot packages are on that OpenUPM registry, I don’t really want that discovery anymore. That must be 10,000 packages. :hushed: Discovery would be near useless anyway. If only they had a system where you had a HOT packages registry that requires a certain number of stars on the repository (for example).

So yeah I too wish the “custom registry” part would be easier, more straightforward, less technical, and not costly. I’m definitely planning on setting up my own registry to understand the issues involved. So far I don’t see a reason why there wouldn’t be a discoverable NPM registry open for the public, besides some running costs.

1 Like
11

Hey all, this discussion has been very insightful in understanding the need to UPM enabled on the Asset Store.

Before jumping into conclusions, just want to take the time to isolate each of the problems you’ve mentioned, would you all be interested in joining an interview session to review the problems you’ve mentioned, sort them and making sure we’re able to produce something easy, fitting your needs and robust enough to scale.

In full transparency, Unity has already initiated the process of making this happen – we would love to have your feedbacks.

If you are interested, please like this post and I will reach out to set up in a couple of weeks.

Cheers,

  • Cathy
2 Likes
12

I would like to know the process of session first, but I am really interest and will take part if I am available

13

Liked! :slight_smile:

@Thaina The process is likely the same as for other interviews ie 15-30 minutes end-to-end video call (likely Zoom).

1 Like
14

In the meantime I would like to present my own solution

This is a script to just curate all installed package, get all dependencies to see if any was missing, then present the wizard windows to let user reorder what and which should be resolved first

Not tested for anything more than 1 dependency as of yet

9466367--1330181--upload_2023-11-12_21-23-37.png
9466367--1330181--upload_2023-11-12_21-23-37.png710Ă—668 22.2 KB