ETA of Asset Store supports Package Manager

Hi @DanielTG,
1) I would like to know when Asset Store can support Package Manager and I hope when it supports Package Manager, I can get the new updates instantly when asset store author ships the new update instead of needing to wait for few days.

2) I hope after Asset Store supports Package Manager, it will have select folder(s) or file(s) to download function instead of downloading the whole package as sometimes u dun want to download very large example scene and u just want the core from the package.

 

Hi @optimise,

The closest ETA (emphasis on the E) that I can share is roughly this time next year until we have extended support for 3rd party publishers and likewise consuming the Package Manager format from the Asset store in the Editor; in short we don't expect this to be available for the Unity 2018.x release cycle.

Thank for you the additional feedback on expectations. It would be great to get more feedback on this topic. Would you expect that Packages follow best practices like separating large sample content into a separate optional package or allow for file selection before downloading?

Any other thoughts/comments on the future experience you would like to see in the Editor compared to what is available today?

Thanks
Daniel

 

Thanks for replying. Next year lol. It's really long way to go. Anyway I think separating large sample content into a separate optional package should be enough. Another really nice to have feature for Asset Store authors are incremental upload that able to skip files that is unmodified directly to speedup upload. So, they can always ship new updates super fast. Maybe u need to create a upload tool to do that and make it as one of the package of Package Manager.

 

@optimise. Thanks for the quick reply. Re: timing. I know it sounds like a long time.We're are starting sooner for sure and will likely have select Packages available on the Asset Store sooner, and likewise available for testing in a beta build sooner than that. I'm just trying to not over promise : ) The key is to make sure that the appropriate publishing workflows (from editor to backend) are ironed out since it's big change, even for us at Unity.

Thanks again,
Daniel

 

From my point of view, separating the package is simply not enough. I'm not sure how familiar UT is with common workflows, but here is an example:

I purchase a package with 3D assets, several GB of content. This package includes scripts (which I never plan to use or compile in my project), shaders (out of which I want only 1 or 2), several hundred MB of textures (out of which I will use only couple dozen MB) same ratio with models and materials, example scenes etc. I import the purchased package in a separate project and examine the package. Only then will I selectively import only the parts of the package that are necessary in the main project. Leaning packages in this way is critical because of re-import times, compilation times, project repo size, assets management and versioning and other reasons.

We need the ability to fork contents from the package, on a per-project and global basis. Since downloaded packages are read only, the only way to do it now is to circumvent the package manager, which gets us where we started from. There are ways to achieve this, with a separation of Package manager UI and Packages Data View (but good grief not reuse of Project View), from where we could create forks that will live in the project (shown in Project View).

 

As an asset store publisher, one thing I'd like to see is dependency mapping across assets from the same (at least) or different (desirable but less critical) publishers.

For instance, suppose I offer an asset called Ultra Landscape Kit that contains a lot of 3D models and textures for rocks and trees. Later, I want to offer Ultra Landscape Kit Volcano as an add-on, but the added content requires the original asset because the volcano spews forth some of the original rocks as ejecta. (This is just a hypothetical.) Since one of the things Package Manager can do is track dependencies, it would be nice if a user who installs my Ultra Dungeon Kit Visual FX package would automatically also install the original Ultra Dungeon Kit if they own it, or at least would be prompted that they have to do that before installing the add-on.

This would also be useful for assets where a runtime core is a free download, but the more advanced features are paid packages.

One major benefit of this would be to allow asset publishers to avoid duplicating a common core across several related (but not interdependent) add-ons, when such duplication could cause import errors.

This sort of thing could also allow asset publishers to rely on the Standard Assets (and I realize Unity is reorganizing how those work) for their demo and example scenes, without actually packaging the Standard Assets or any subset thereof with their own asset.

 

I'm not familiar with the package manager yet, I'm currently importing a lot of assets into a new project. My personal preference would be: Please get rid of the meta files. Instead maybe make 1 file a registry or something like that. The meta files double the total number of files. Currently I'm at 30.000+ instead of 15.000.

 

I'd also be interested in an updated ETA. Will we be able to publish with the new package system on the Asset Store in the next couple of months?

 

Yes please, it can be a game changer

 

Hi everyone,

Unfortunately I have no new ETA for when the Asset Store will start support the UPM (Unity Package Manager) package format for publishing and hosting.

Related to Asset Store, the Package Manager team have been focused on supporting the native "My Asset" .unitypackage workflow in the Package Manager UI (starting 2019.3 and improved in the 2020.1 alpha). There are still many workflow limitations with the UPM format for authoring, publishing and importing the bulk of Asset Store content (particularly assets that are 'editable' not read-only, and selective download and/or import) that still need to be planned and addressed before it becomes a viable format option for the Asset Store.

I understand if this update is not ideal. I appreciate your patience and understanding in these delays.

Thank you,
Daniel

 

Thank you for the update, even though it's very bad news. So two years ago, it was "in about one year", and now it's "no new ETA". I can see the issue with read-only - something I found tremendously annoying with UPM, anyways. Basically, what I would want there is that once I have added a package, Unity should never mess with it unless I explicitly click on a button like "update" or "restore". The current behavior where I need to copy the package over into another folder feels like quite the workaround. I checkbox in the preferences that says "Don't mess with my packages" would be greatly appreciated, and IMHO would also solve the issue with editable assets from the asset store.

Regarding selective download: I think that's a great-to-have feature but with the previous change (i.e. I can change the packages without Unity restoring the original version on the next start), it shouldn't be something keeping you from delivering UPM-based Asset Store packages.

 

sorry for reviving, but I'd love to see this sooner than later too. as of 2019.3, the current asset store upload system still doesn't play nicely with UPM-enabled packages

 

@DanielTG “I appreciate your patience and understanding in these delays.”

I personally don’t understand why no solution has been found after 2 years of trying. Is it maybe time to ditch UPM for ‘My Assets’ if you can’t even tell us that the PM team has found a solution??

You could :

- move the Package Manager to the Hub. No one needs to update unity packages inside the editor; this can be done before launching the editor instead of mid-session.

- keep “my assets” separate from the package manager and use git as a backend for it? That would allow us to have granular control over what gets downloaded / updated and when. If asset store packages were kept on a private Unity git repo, you could allow access only to people who have bought the asset?

 

Sure, they could make a thing that takes 10 seconds and make it take 30-60 seconds but why? I very much need the ability to add packages while the editor is running to be able to use Unity faster (PM itself is super slow and it should let people to queue updates but that's another topic).

 

lol, for the love of god just expose the assets via FTP. Do you guys hire devops or what? So many Unity problems outstanding for years that a seasoned devop would fix in a weekend.

 

I don't think that we retroactively need all existing Asset Store assets to be packages. Going forward why not let Asset Store developers choose to deliver their asset as either a "My Asset" .unitypackage or a Package Manager package when appropriate?

For an asset that is a bunch of 3D models a "My Asset" .unitypackage makes sense. It probably wont get many updates and the user may want to selectively import the specific models they want.

For an editor extension or code library it would be better as a Package Manger package. The user should be discouraged from changing it, and Package Manager packages are better for version management.

 

Agreed, I think it's important to distinguish between asset-only packages, and tool/library packages. It'd be great to have a field when submitting, to choose whether to "install" asset store purchases as an asset-pack, or as a package.

 

I did some digging... I think Unity may already allow UPM packages in the Asset Store, and treat them as such in Unity 2020, but it isn't documented yet?

I noticed this post where @transat says this Asset Store asset gets treated as a UPM package. Then I found this in the Unity 2020 beta release notes:

I'm not sure what causes an uploaded Asset Store asset to get treated as a UPM package, but if I had to guess I suspect it's the presence of a package.json manifest.

 

There's nothing like that. The package manager UI simply fetches info from the asset store and manages downloads of the old .unitypackage format. It's just a new front-end for the same functionality of the in-editor asset store.

 

@JoNax97 That's been my experience as well, and I think that's true for most Asset Store assets right now. Did you see the @transat post I linked to though?

 

Oh I misread you. Well it looks like they're starting to roll it, or at least making a private experiment for selected authors. Let's hope we get some official word soon. Sorry about the confusion.

 

ah this is interesting! I'll have to take a deeper look into this, cheers!

 

I don't agree with that, especially for code-packages. I find myself more often than I like fixing small bugs and issues in Asset-Store bought libraries, I also write the devs about them, but I can't always wait weeks or even months for the fix to arrive, because either the developer postponing it for a planned release some time later, or the verification process of the asset store takes to long. The last two times I fixed a minor issue took me 20-30 Minutes the update from the official side, both times took four weeks to three Months. Which is unacceptable if a game-feature heavily relies on the package and can't be developed without either recreating the asset as a whole or finding some ugly workaround (if there is one).

Edit: Also it's very annoying if you have to copy the package content to your project to modify it for the time it takes the developer to fix it and return to the package version when the update comes. That's a horrible workflow.

 

@Nefahl I'm not saying you shouldn't be able to modify a package or apply fixes yourself. In fact I think Unity should put all their packages up on GitHub for that reason. What I am saying is that you should be discouraged from modifying the version managed by the Package Manager. Let me give you an example.

Say you are brought in as a new developer on an existing project. You pull down the project from source control. In source control the only information about what packages you are using is the Packages/manifest.json file which says the package names and versions. When you see that you know that for each package all it needs to work is to download that specific version from the package server. That's what the Package Manager does. If you need to make a modification, then you no longer want that specific version from the package server, and you want to add your modifications to source control. So you need to remove the package from the manifest and bring it into your project to track your changes. That is until new versions from the package server fix your issue, then you can remove your custom version and add the new version from the package server to your manifest. It's a perfectly fine workflow in my opinion. What other workflow would you propose?

I will add that it would be nice if package developers made more of an effort to allow their code to be extended. So to fix a bug you could create a new class that inherits from the broken class in the package and overwrites a problematic function, for example. In that case you wouldn't need to bring the whole package into your project and remove it from the manifest.

 

I am very disagree with you

The mindset of `shouldn't be able to modify a package or apply fixes yourself` is wrong. We should. Everyone should. With every code and everything in the world we should have freedom to fix or modify code we use

This is the sole problem of unity package manager system itself that it was not designed to have this mindset in the first place. It should fix the design itself. It should just use git system and be aware about local version of package and project. And the developer team should responsible for themselves about versioning and how to share package dependency

Actually UPM dependency system is also flawed in itself that we need to delete or manipulate locked file manually just to reimport package

 

@Thaina Did you read my post that you quoted? I actually agree with you that you should be able to modify and fix the code from packages. Their source code should be available to you.

I think there is a misunderstanding though about what a package manager does. UPM is based on the NPM javascript package manager. They both work the same way. There is a server that hosts packages. In your project is a manifest file that says the names of the packages and their specific versions that you want from the server. The package manager goes and downloads that specific version of each package.

If you need to modify the package, I agree you should be able to do that, but you no longer want the specific version from the package server. You want your custom version to live in your project and your source control. One way to do that is to remove the package from the package manager and add it to your project instead. You can actually still use the package manager with your custom version if you make the package a local or embedded package, or run your own package server. What you should be discouraged from doing is modifying the package without telling the package manager that it's now a different package/version from the one on the original server, because it will overwrite it. That's all I'm trying to say.

 

I know and understand. But I try to point out that it was the wrong perspective

UPM based on NPM is not a great things from the start. Because unlike NPM or even nuget, unity code require patch and fix all the times. And it was and should be made to support scenario of patching and extending

What I try to point out is, yes, we never need `the specific version` from the start. We just care about working version we have pulled. When we pull package into packagecache, that was already a version we really work with

I can't put it into word but what I try to say is, it was unity who make a flawed design in package system, not people who try to modified package. They should be able to do but forced to avoid doing it, which is wrong and you should not talk in the way to stop or them, instead we should force unity to accept this problem

We shouldn't need to care about version. We just want to use package, any version is fine as long as it's not break things, that's why NPM support SemVer. But the use case of unity is difference and that's fine to not support SemVer. But on the other hand I think unity could do better, it should support custom patching and freedom of extension

The way you talk and your perspective is not in the right way that's what I try to say, unity should doing work, not the people should stop doing what they should be able to do

 

@Thaina It sounds like your complaint is more with Unity's code quality than the package manager. In my opinion we have a much better situation now with all these features as packages then we did before when they were built into the engine and there was no access to the source. UPM packages are supposed to use SemVer. If you have specific ideas how Unity can better support custom patching and freedom of extension I'd love to hear them.

 

Hi,

From reading this thread I understand there is no official support to sell package through the asset store (yet).
Seeing how heavily unity invested into packaging it own code, and the preview package developement package, I don't see unity not supporting third party package sells through the asset store.

With those assumption, and having started to devellop some packages, I jump in to share my early thoughts one big stuff to take into consideration for such support.

One of the main benefits of the package architecture is the ability to manage dependancies. This allow to develop small package individually making them easyier to develop and maintain. To keep that benefit, the first question arise. How will a publisher be able to sell dependant packages through the asset store ? let's say I have 3 packages A,B and C.
A is a free independant package, B is a paid package (5$) with a depedancy on A and C is a paid (8$) package with a dependancy on B. How can I define my pricings. If someone bought package B and finds himself in the need for C, He will have to pay 8$ again. Where the person that baugth the pacakge C for 8$ either will get a free package B ou a non working pacakge C. IMO, unity team need to think about flexible/configurable pricing stategies to allow third party to offer discount on already bought package. We should be able to say if hte user already has package B he will only pay 3$ instead of 8$ or whatever pricing strategy the third party want to define.

We also need some automated way to display dependent assets/package so that the end user has no chance of buying an asset and find out later he has to by something else to make it work. The display should be automated for such dependancy so that the publisher can't avoid aknowledging the dependancy but the publisher should be able to celarly say for what features this dependant asset is required (for instnace, all features are avaiable for stand alone game but you need pacakge X for networked game and package Y for "cloud asset management" and analitics to work).

 

Not exactly just unity own code, the unity script code from any package always need patching for various reason. Sometime even google firebase made a serious flaw leaking code. Because unity system is so complicate, building on C# then convert to cpp and forced to be run on native. It also have many sideway jack in (like PostProcessAttribute) not to mention versioning and deprecated also old package that stop supporting

The package manager itself just not accounted for freedom and force complicate workflow on us, unlike old unitypackage that just explode directly and so we could always modified it

I totally agree that UPM have made us better life but because the package and unity itself are always unstable it was a tough choice to migrate into UPM workflow because we then lose freedom to modified things

In my opinion, UPM should just use git all the way down from the project to each package
If UPM are bound to git system directly, it's meant we could modified any package and it would aware about local change and branch, we could specified package we want and branch it at will, we should have freedom to fork package to new remote path. Then we can manage by merge or rebase for new version with common git management

 

@Thaina @sbordenTurner
I really didn't thought about the way you describe about handling your own version and agree with most of the points you've made. The best solution (from unity-user perspective) I can think off, would be some UPM built in versioning. Let the users of a package "unlock" it for modification and store the diffs in some packagesystem meta folder to be shared with the manifest, just like the user would do manually via copy/pasting and handling the diffs in a extra repository. Ideally let the user iterate over the diffs/patches when updating the original package and see what diffs are still needed (for sure need to be merged manually but that would be fine by me), or which changes can be discarded, that way you spare the user all the trouble with setting up & maintaining several repositories per project, especially where only small patches are needed. Additionally convenient would be to let the user share the patches via unitypackage export/import or something alike.
I think that would really fit into the Unity ecosystem of trying to make everything as simple as possible for the user to understand/work with. They could also leave the possibility to manage the packages in custom repositories for those who prefer it that way.

The way it is now, is in my opinion a horrible workflow, especially for small studios and solo developers who will need to sink an exaggerated amount of time to copy/pasting the package setting up a custom repository, rewinding if a new version fixes the issues and even more if only a few issues get fixed. And even bigger companies who maybe can afford employees to sink their time in maintaining that package-state, would be happy to have their staff spend time in a more productive manner, I bet. As long as this stays the way it is now, I prefer the old asset store way of doing things, which is far from optimal by itself (having to delete and reimport the package to remove no longer used files for example). The new system does many things better, but other things worse. No big improvement yet, just different but I'm sure that they can improve on critical feedback more than on "Ohhh everything is so shiny and great!"
(Not implying here that you said so, your arguments are valid, thanks for the discussion )

And as a side note I'd really love support for private git-repository support for packages to maintain my own packages without the need to setup a private package manager server, but thats off topic...

 

Any news?

 

I'm not asking to provide this feature. I just want to know the right way to publish my asset on the Asset Store.
My situation is:
- I'm creating a plugin that contains a lot of code, one shader, and one texture.
- Also, there is an example folder, with sample models and scenes to demonstrate usage of my plugin.
- Code has dependencies on Burst and Jobs packages. Also, optional URP package.
- I structured code to be UPM-ready, (Runtime/Editor folders, package.json file, asmdefs)

The main questions are:
1. How to combine code and example folders in one package.
2. Is it possible to move the code folder under the "$ProjectName$/Packages/" folder when importing asset into project?
3. What is the best way to provide examples? In my opinion, ideally would be to have 2 separate packages. That way you can import only code if you are already familiar with the asset.

Thanks

UPD
So that's how we should handle upm dependencies?
"1.2.g Assets with dependencies from Package Manager should only include the necessary packages for the asset to work. Use the “Include Dependencies” feature in the Asset Store Tools to include the packages."
Source: https://unity3d.com/asset-store/sel...11.2090937781.1610357898-747190097.1591625021