Search Unity

As more features in different stages of development move into packages, choosing the right tools for your project can be challenging. Updates to the Package Manager in Unity 2020.1 and to how we list packages in the Package Manager will help make it easier for you to consider the impact of using preview packages in your project and achieve a more predictable development experience.

Using preview packages has its risks. For example, API or functionality changes could disrupt the continuous usage of the new tool in a production environment. On the other hand, we know many users enjoy being on the cutting edge of Unity, and trying prerelease technology can help teams prepare the tooling necessary for future projects and anticipate opportunities. Feedback from early adopters also helps us to make better tools for everyone, so we’re working to provide more clarity so users can make more informed decisions for their project.

If you want to add preview packages, you need to expose them through a checkbox in Project Settings.

Goals for packages

This is the first step in a series of measures that we are working on to help make it easier for you to explore the latest Unity tools and features. Our goal is to make it clearer which packages can be considered safe to adopt for full production and to give an idea of when a package will be verified. At the same time, we want users to be able to access experimental packages for early testing and feedback.

Revisited list of packages discoverable in Package Manager

In a company-wide effort, we reevaluated our package list to identify preview packages that are either more experimental than production-ready, or else not under active development. In Unity 2020.1 and later versions, preview packages in those categories will not be listed in the Package Manager. However, if you’ve already installed these preview packages, they won’t be removed from your projects – you can continue to use them, and they will still be able to receive the available updates.

Our intention is to include preview packages in the Package Manager when the development team believes that the package will be verified within that version’s release cycle. For example, if a preview package is visible in the Package Manager in Unity 2020.1, we plan for it to be verified by the time we reach the Unity 2020 LTS release. Naturally, things can change, but this is the initial guidepost we have used to filter which packages are visible.

Packages that are in the early stages of development or considered experimental will remain available in the production registry. You can still add them by editing your project manifest. See this forum post for the full list of packages in this category.

We’re still working on ways to make packages clearer for users, so your feedback is welcome. If you’re interested in contributing feedback about preview packages, sign up for the Beta tester newsletter. We’ll be sending updates on new packages available for testing, even if they’re not discoverable, and sharing details on how to use them and provide feedback to our development teams

Learn more about Unity 2020.1

Want to start using Unity 2020.1 right now? Get more details on upcoming features and improvements in the 2020.1 beta announcement blog and the 2020.1 beta overview webinar.

If you’re interested in hearing more about upcoming technology and connecting with developers at Unity, sign up for our beta newsletter and follow the beta forum.

38 replies on “Package Manager updates in Unity 2020.1”

Well this is now live for less than a day and the post are flooding in asking where packages are. The other alarming repercussion is people are blindly posting manifest.json files around. Unity needs to jump on this fast

Thank you for taking this decision. I understand it was not easy and won’t please everyone, but I think it’s a good move in the correct direction.

This seems like a MASSIVE step backwards. Why not have the option to show «preview» packages and then also have one to show the «prototype» packages? And for the packages that are planned to have no further development, if that’s the case, why hasn’t this been communicated to us?

There’s many problems, all summed up in previous comments.
I would ask this same precise point: rename ‘preview’ to ‘prototype’.
Keeping the word ‘preview’ is just…insulting. At best.

The whole concept if «preview» packages is broken. In reality, users are forced to use latest «preview» versions not because of the reasons you listed, but because they contain fixes to critical bugs that make «verified» versions simply unusable.

Example: Addressables. I don’t know of any reason anyone would want to use «verified» version (which is now ancient) instead of the latest one.

The one feature that makes the horrible package manager worth it, you want to remove it…

Who is making these decisions….please reconsider

Yeah this smells like some corporate guy showing his appendage where it doesn’t belong. Corporate guy, go harass the interns and leave us alone.

A couple of questions come to mind.

– Why make a new main entry in Project Settings that holds just a single toggle setting? You are crowding the menu. Perhaps a show/hide toggle belongs locally, close to the elements being hidden and shown. If the intension is to make the setting harder to find, so that fewer people use preview package, perhaps 1) rethink the UI instead, 2) adopt alpha-beta terminology, 2) stop promoting new packages widely before they are ready for a wide audience.
– Why are you asking users to edit manifest files manually again? Why not design UI that guide and warn? Perhaps packages that are not updated since X months could be marked as not under active development. Or perhaps let users rate and review them, just like Asset Store products.

Other hurdles with the Package manager.

– Why do users still have to spend time removing unnecessary packages every time they create a new empty project?
– Why does it take so long to remove packages, one at the time?
– Why haven’t you reached out to Asset Store developers, providing clear instructions on how to conform to the package manager file structure / layout? Tutorials are missing. The «Package Development» package is still in preview. The manual is helpful, but in practise, I am still confused. For example, how to ensure that packaged shader include files referenced by user shaders in the asset folder keep valid paths when switching from «In -Development mode» to production?

Otherwise, great work with the Package Manager. I look forward to making things that integrate well with it.

Alright, now I am completely confused by Unity.
As some others have already said, this is a huge step backwards. You have already LITERALLY put toggles in the Project Settings to prevent Preview Packages from showing up… And now you’re removing Preview Packages entirely? What happened to «we’re improving the packaging manager!»? It was literally on this year’s roadmap! And now… You do THIS? Preposterous.

Being a person who uses the cutting edge of Unity and supports it — this seems pretty dang wrong… But I know WHY you’re doing it. I just think your methods are pitiful, band-aid solutions that bite the developers who want the future of Unity as much as Unity does.

And as for the WHY… If you didn’t want people to be using Preview Packages that clearly were not ready for the wider Unity audience, can you please tell me why the heck you keep promoting DOTS and other in-preview technologies? I mean THAT’S the reason why people are adopting things too soon and then coming to the forums and complaining that the Preview-Packages are trash. It’s because you are promoting something that ISN’T READY to be put out into the world. And now you try to fix it with this «solution.» Ugh…

Unity — DO NOT DO THIS TO YOUR EARLY ADOPTERS.
It’s a bad decisions that you’re making on top of a LOT of bad decisions that led up to this issue. If you don’t want people using Preview Packages (Which really should be called «Prototype» rather than «Preview», or «Alpha»), then you should put explicit warnings when attempting to use them that the technology is an unfinished, possibly broken, prototype, that should only be used at your own risk. END OF STORY.

And don’t get me started how you literally made a SURVEY asking people what kind of improvements they want for the Package Manager and then you immediately turn around and do THIS.
That one’s just beyond me.

There is actually a difference between the Preview packages that are still discoverable in the editor (with the preview setting toggle) and the ones that were removed from the discovery list. The preview packages that are shown are the ones that are on their way to become verified (in the year or so). The others were experimental packages or packages that are used internally by other packages and not meant to be used by all for production purposes.

The goal here is to make it clear to our users what is production-ready or not.

Yes, but in doing so you have slapped the entire DOTS community (and everyone who uses Unity’s cutting-edge) in the face.
Isn’t that fantastic?
Fantastic.

Mmmmm. I suggest not eliminating said packages that will now need to be manually added via the manifest. That creates MORE HASSLE for developers. It would be simpler to create clearly labeled categories to list these packages in the package manager. Between this and the licensing model for Project Mars, I’m becoming concerned with Unity’s recent decision making processes.

All the packages that were available will still be, with the only difference that they will need to be added manually. We are looking into ways to make it easier for experienced users to use these packages. For now, you can use the «Add package from git URL…» option and just type in the package name (e.g. com.unity.mathematics) and it will instantiate the latest available package from the production repository.

Thanks for your suggestion about the labeling.

This is a great move — thanks!

That said, the list of packages is currently slightly worrying — Entities, for example — including some things we thought were going to be ready for 2020 LTS. Hopefully the statuses of some of those will change over time.

Please, add the possibility to install 3rd-party packages from git with respect to their dependencies. Like npm. There are things like openupm.com to overcome this limitation, but it requires the preinstallation of additional software(custom git cmd line). For me, the developer, it might be ok. But I work with designers and I need them to be able to easily download and run my project, without additional and complicated steps.

Please! Let Unity community build a powerful network of tools!

Please actually explain which packages are no longer actively developed, as if you yourselves admit that is happening why allow users to continue to rely on them if they DO NOT KNOW OTHERWISE???

This is a huge step backwards in my opinion. Manually editing the manifest file was embarrassingly bad the first time around. Going back to that is inexcusable.

Make a preferences option for whether alpha packages should be visible or not. Default it to NO so it will take some manual effort to turn it on, and not have this visible for everyone. This would at least be doable for trying these features with my students.

I totally understand the need to do this and I support this decision. No sarcasm. I don’t wanna see not-ready-to-use packages in the manager which confuses me and others working with me. Like AAA games need to be ready to play on release day without major bugs, Unity packages must be included in the Unity experience when they are «almost» ready.

«…or else not under active development»

Is there a list of packages that fit that criteria? Just so us developers don’t unwittingly hitch our cart to a dead horse.

Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, make it possible to add/ remove multiple packages at the same time!

Due to the long wait and load after removing a package, it takes far too long to remove all the useless default Unity packages that are added to new projects.

That reminds me…is there a way to save a project as a template, other than manually copying a folder. I feel I should be able to create my project with my shosen packages, and then just itterate on them. I swear I’m rebuilding Unity to my satisfaction every other week.

This is the direction we are heading. As we are working on new templates, we will make it easier/possible for our users to do so as well.

That call the «Package/manifest.json» file in your root folder ;)

(I did a script in my facilitator that allows to remove several package at a time.
I need to improve it a bit to add directly links of the new one to add.)

How is the company that makes a game engine not using software release terms like alpha and beta? Expecting major changes in functionality as the package is bleeding edge? It’s an alpha release. Expecting generally stable performance with maybe a few minor tweaks before production release? It’s a beta release. Why does it need to be so complicated?

Most of the design decisions for Unity Package Manager were inspired by existing managers like npm. The naming of the version was up to the developer. With time, we realized Unity users wanted to know more, so we came up with tags for Preview and Verified packages. As we are moving forward, we are making small adjustments to this.

The package manager in its current state reminds me of Netscape in 1995 when you were about to click somewhere and all of a sudden — right when you click — something different pops up and you activate that.

Background loading is nice and all, but it should be blocking the package manager UI itself and be cancel-able.

Let me echo what Jes said in the first reply to this blog post. As developers, we often want to have easy access to early «Prototypes» knowing full well that they are bleeding edge. Rather than having to edit the project manifest, which is a cumbersome process and prone to error, allow developers to add Prototype packages like other Preview packages. Packages should be easy to add and remove. Manual editing of manifests gets in the way of effective developer workflows.

But let me add one more suggestion on top of this… Make the Development Build in the Project Build Settings automatically enabled if there are any Prototype packages in the Project.

All the packages that were available will still be with the only difference that they will need to be added manually. We are looking into ways to make it easier for experienced users to use these packages. For now, you can use the «Add package from git URL…» option and just type in the package name (e.g. com.unity.mathematics) and it will instantiate the latest available package from the production repository.

Please follow the forum thread here for more details:
https://forum.unity.com/threads/visibility-changes-for-preview-packages-in-2020-1.910880/

Cool for start thanks :)

Please consider option to just get rid of preview label and replace it with prototype label for packages that will not ship any time soon and checkbox in package manager to se them instead of separate registry.
for packages that will ship in current major unity version consider to use worldwide used stage labels (alpha, beta, rc)

Yes, «prototype» is more appropriate. I think they use this branding marketing technic to attract more people to use and test the product in the beta stage. But that user that was thinking it was a preview in the final stage is disappointed and complain.

Comments are closed.