Official Introducing Feature Sets to Package Manager

Quick glance and opinion:

Does it mean we finally will see the default new project without a ton of unnecessary packages? It would be about time. It's a bit tiring to remove all not needed packages one by one every time I make a new project (which is frequent since I started to work with many "subprojects" for separate aspects of games and merge them together only the bits I intend to use into my "final" project where I build the game).

Why would anyone want to install all of Visual Studio, VS Code, Rider together? The first thing for me is to get rid of the VS ones (I use Rider only). It is not different if you use VS or VS Code either. You should add choice to this feature, so before the "Install" button I can select which one editor support I intend to use. Plus add Version Control maybe? Although I don't use any of Unity's solution either. For an indie and especially for a solo dev, you have one reasonably priced version control service and one working. Not a nice choice.

I would like to see support for experimental packages. One stop shop DOTS install for example.

The roadmap is empty for me.

 

Because it is pretty common to have different IDEs being used between different team members. It may not a thing for a solo developer though, so most likely you would disable that feature set in that case.

 

Interesting. I only worked in teams where it was decided what tool the entire team should use, but never individually, that's kind of recipe for a hidden disaster.

That's the thing: as a solo developer, obviously it's not a question, but in my experience in a team it also isn't a question because of the team decision. I guess ragged teams, where people are randomly get together under no strong management are using random editors.

 

Yeah, it would be great to have HDRP in a feature package where you could bundle demo scenes and such along with it for people who need it and just barebones packages with project setup with defaults for others who just need the packages/features.

 

I would love to be able to make a set of assets that I imported into my project from the store. So that If looking for updates I don't need to look all over the place for updates but only inside a group

 

I am wondering if you could extend on the concept (and goal of helping developers manage compatibility of packages) by using deep analytics for all packages, including asset store ones?

What I mean by that is that you could expose anonymous data gathered from Editor analytics containing:

• % Editor versions actively using / crashing with / failing to build X package + package version.
  • Helps determine if they are compatible or not & which version is the most stable
• % Users reporting issues with other packages.
  • Implement a -very- quick & simple way of reporting if a package is working or not (thumbs up/down, or similar) and if not, automatically report and cross-check package manifest with other users reporting issues to help narrow down which packages are problematic.
  • Gives more granular information on which packages could create issues with a specific package.

Exposing more analytics to everyone (including your own developers) can be a win-win solution that can alleviate a lot of frustrations while helping identify when/if packages created regressions. And it can be done right without exposing sensitive data (just use %, keep it all anonymous).

Just be mindful that the key for this to work is to implement it properly so it's very easy to access and read the information. If you end up having the user click through 3+ levels of links / charts to get the relevant information, you have failed.

 

This is going off-topic, but Unity is not tied to a single IDE in any way, so there is no reason to not allow different IDEs according to each team member's taste. Where I work we use Editor Config files to ensure standards, which is compatible with all major IDEs (VS Code, VS Studio and Rider).

 

This is going off topic.

I don't care if you have a team where you all use different editors; do whatever you like.

The point being made is that any package group should include the minimal possible set of packages to run. If you want other packages, then opt-in, don't force people to auto-opt-in and manually remove packages.

Why is `TextMeshPro` a default package now?

Why is `Unity Collaborate` a default package now?

Why is `Unity UI` a default package now?

The package manager already includes a mechanism to have 'internal system packages' like 'com.unity.modules.physics2d'; if it is an internal system package, mark it as such; but these are not internal system packages, you can uninstall them and it's fine.

They're just bloated crap-ware that is added in for no obvious reason; this is highly undesirable behaviour in a package manager.

With regard to actually desired features:

> Tell us which new Feature sets you would like us to create

I am totally uninterested in your efforts to create feature sets; you've completely bollocked it up so far, and there's no obvious reason to suspect you've learnt your lesson and are going to do a better job of it now.

Please allow the community to define these feature sets and put them on the asset store; I also manually deploy my package manifest with 'known good configuration'; it would be nice to be able to have other folk do similar things.

You think unity should have 1st party feature sets? Awesome. I do too; but, please put them on the asset store. If they are good, they can compete with the other feature sets from 3rd party developers like the existing unity assets.

> Are these defaults?

What does this question mean? Are what defaults?

> Would you want to be able to customize them?

Yes.

> Build your own?

Yes.

 

One more: I would put the feature sets below the packages list. We use the feature sets (if even) only at the beginning of a project (usually), but we use the package browser more often for updates and/or install individual packages as needed.

 

Look, it's very simple.

If you install a package A, and it depends on package B, then using semantic versioning, if you install A, it should install a version of B that works.

Semantic versioning right? 1.0.0 means it's ready right?

https://docs.unity3d.com/Packages/com.unity.mathematics@1.2/changelog/CHANGELOG.html

> 1.2.1 Internal (Not ready for production)

I mean, just read these changelogs:

https://docs.unity3d.com/Packages/com.unity.addressables@1.18/changelog/CHANGELOG.html

https://docs.unity3d.com/Packages/com.unity.formats.alembic@2.1/changelog/CHANGELOG.html

https://docs.unity3d.com/Packages/com.unity.xr.oculus@1.9/changelog/CHANGELOG.html

https://docs.unity3d.com/Packages/com.unity.render-pipelines.universal@10.5/changelog/CHANGELOG.html

I particularly liked the URP upgrade from 7.0 -> 7.1

> The render pipeline now handles custom renderers differently. You must now set up renderers for the Camera on the Render Pipeline Asset.

Don't worry, that's a minor point change, we're just... adding... a breaking change....

I guess it depends what you consider a 'breaking change' to be... if all the scripts still compile and it just breaks projects, it's not a breaking change right?

Look, I get it, doing semantic versioning is hard, and with many different teams, maintaining strict semantic versioning is tricky; but if you depend on a package, and the version of a dependency that is installed is broken, you've screwed it up.

I've personally been affected by this multiple times.

...and look, frankly, I'm openly skeptical that the internal processes to adhere to semantic versioning are applied uniformly across all internal teams; I think just looking at the change-logs from different packages even now (and you're doing waaaay better now than we were a year ago) that different standards and practices are being applied on different packages by different teams.

You must read the package manager forum right? ....so, I feel like I didn't have to write this long reply, since, you should already know how people feel about this stuff. ...but, you asked.

After reflecting on it, specifically with regard to this feature:

- I generally like meta-packages; they are helpful for installing 'many at once' dependencies (since you still can't do this). The 'features' view is strange; why are these not just normal packages?

- Wouldn't it be nice if you could have a meta-package that included all the dependencies and a package 'sample' for the starter projects? Then, rather than having the project templates in the unity hub you could have semantic dependencies for project templates.

- I still think there's tremendous opportunity in allowing asset store authors to 'group' their assets into features like this.

- I'm annoyed that the package manager still can't show (or I haven't figured out how to show?) a full hierarchy of the packages *before* installing them; the only way to know what you'll get is to install everything and then look at the lock file.

- The game play feature depends on VS 1.7.1, but you can go and install 1.7.2 manually if you want to. It warns you *after* you've manually upgraded, but the main package manager *suggests* that you upgrade; it shouldn't do that. You should be warned before you upgrade that you're potentially breaking an a 'verified' feature group.

...

PS. It's alpha, I know, but I feel like as I write this, when I create a new URP project from the template, and the first thing I see when the project opens is:

> NotSupportedException: ForwardRendererData has been deprecated. Use UniversalRendererData instead
UnityEngine.Rendering.Universal.ForwardRendererData.Create () (at Library/PackageCache/com.unity.render-pipelines.universal@12.0.0/Runtime/ForwardRendererData.cs:55)

...is some deep irony. I am *so* convinced you guys have this under control.

 

I also agree with this point, this will also remove the 100 MB demo content limit that you guys have (it was mentioned by pierred_unity in some post) when it's included with the project itself and would allow for better showcase scenes.

 

Just when I think Unity is beginning to understand how to make an engine, they make it the responsibility of the random public at large again, most who have never shipped anything.

I do not think this is a good idea at all. I think all packages should work together, separated by mono and DOTS. If you make an engine, it all works together. What's this pick and mix cop out feature sets concept?

There should only ever be 2 things:

1. DOTS
2. NOT DOTS

Why does this sort of feature sets thing set all kinds of business alarm bells ringing? Can I trust Unity to chart a course, when they're asking everyone else to draw the map?

 

What is more, wouldn't the same person asked about this, change their selection constantly? It would be a different answer per project, or even as the same project evolves. It would be forever-changing even for the same person. I think I would need clarification what this feature is intended to solve.

Are you talking exclusively about learning materials and not core engine features? Or asset store packages? I can see it being useful for starter assets, but these are assets, not engine features as they are made with the pre-existing engine for the purpose of accelerating someone's game development, and I am still unsure why it would be a part of package manager.

 

Nice to see that instead of a cautionary tale, they took this meme as a guide. Now you need to make even more choices about the project you are making before you even start making it.


Docs UI Page:


Flowcharts about GI:



And now feature sets, where they more or less admit that their features are not designed to play well together.

 

To be fair, asking this... did you actually try the feature?

These packages are simply meta packages, they look like this in the manifest:

Code (CSharp):

1. "com.unity.feature.gameplay-storytelling": "1.0.0",

and this in the lock file:

Code (CSharp):

1.     "com.unity.feature.gameplay-storytelling": {
2.       "version": "1.0.0",
3.       "depth": 0,
4.       "source": "builtin",
5.       "dependencies": {
6.         "com.unity.cinemachine": "2.8.0-pre.1",
7.         "com.unity.timeline": "1.6.0-pre.5",
8.         "com.unity.visualscripting": "1.7.1"
9.       }
10.     },

It is literally a zero content, one-click install for several unrelated package heirarchies.

The UI looks like this:



It's obviously related to all packages not core engine features (which aren't discoverable in the package manager anyway), and intended, see:



To group 'known working package versions'.

Well, yes. That is the ideal situation. I'd like that too. Pfft. I'll believe it when I see it though.

 

Thanks for the post. I am aware but you should be giving Unity feedback and not me feedback, unless you are Unity staff. That's the point. To talk to Unity, as they have requested.

 

And here I was thinking that this is like Rust Cargo features. Maybe one day, but now the name is kind of taken.

 

I personally liked it, it bundles several features that we normally use together (Example: I always use probuilder + polybrush, it's impossible to use one without the other) so, downloading the version where both are compatible with each other. awasome

Still, I agree with the previous post. Packages aren't installed in the project by default, so the editor doesn't get bloated, full of useless features for a project, that's great. But at the same time, all packages MUST WORK TOGETHER, they cannot be incompatible with each other.

Downloading a package should not prevent me from downloading another package, or using another package, they must work together.

 

Which would probably be redundant if you could install multiple packages at once, for which you currently have to edit the manifest.

 

It is a nice idea to install multiple packages at once, but to tell the truth I wouldn't use any of the built in ones. Normally I only need a few of the packages in any give Feature Set, like the "Gameplay and Storytelling", I don't need the Visual Scripting, but the other two would be nice. So it just feels like less work to go install each one my self.

I feel like Feature Sets as they are now would be better presented as 'group headers' within the main packages list that could be collapsed/expanded. That way I could just collapse the header to hide all of the packages in it(I have no need to see packages for 2D when working on a 3D game, same for XR). I think it would also allow you to find individual packages faster when just looking at the list.

I think this would also make better use of the screen real-estate.

I haven't done a lot with making my own packages that have dependency, so forgive me if I am talking nonsense or if this is already possible. But being able to make "Features" that include local or github packages would be
extremely useful. Far more than any built in ones that unity could make.

Using the "Go to package view" button I think highlights a very painful point, which is that the Package Manager window is very slow when trying to find packages, this is very noticeable also when searching. It is slow enough that I can't see my self using the "Go to package view' button because it feels slow and I lose my place in the window. I also never use the search because it feels faster to just find the package manually.

In short, my feedback would be:
- Move built/default features to be group headers in the main packages view, or just don't include default ones.
- Allow for making custom features with custom packages.
- Increase performance of finding packages.

I hope this feedback helps, I don't think I can stress how much I would prefer these to be group headers, I can not see my self ever using any of the built-in Feature Sets, but having them as groups would be very very nice. I do think being able to make groups of packages like this is very handy!

 

Agreed

 

Need to be able to install each package individually from within the grouped package, just add an 'Install' button to each of the single packages listed within the group. And leave the 'Install' button at the bottom, for installing all packages at once.

This will make it easy for people to quickly find and install related packages.. just search in the group. But, if the group forces you to install 2 or 3 packages you don't need, which will be the case much of the time, then going that route becomes useless.

 

Instead of these so-called new "Feature Sets" I think finally adding support for chaining Git Dependencies would be INFINITELY more important and powerful, especially since this would implicitly provide the same functionality these Feature Sets are supposed to (if I understand this correctly).

So if you wanted to import e.g. a "Demo" package to your current project you could simply add its git url via the package manager and it would import it and its base dependency package(s) (e.g. a code library package and an asset library package) and if any of those have further dependencies those would get imported as well.

 

It would be nice if you just grouped things for clarity.
i.e. Group up all the editor packages (rider, VS, VS Code) and related things (test framework, Custom NUnit (?!)) into 1 group. If there is no real issue in having additional plugins for editors you do not use, then just make it an overall 'Editors & Test' package.
In fact does it even need to be a package and not part of Unity to go back a step?!
As it is a new project has 5 packages which could be combined into 1 package or 1 group of packages to reduce clutter

 

I already hate it when Unity takes forever to import all these default packages I'm never going to use after I create a new project and I then have to spend additional time removing them one by one...

 

I was going to ask how to make custom feature sets, but reading this thread it seems that a feature set is just a normal package with no content but only dependencies? That's it, or is there anything else?

 

I missed this - extremely useful instead of an A-Z list of plugins as we have now

I think the real info from this thread is that packages could use some love and this 'Feature Sets' is not as important as improving the packages system and UI first and good grouping of packages may make it redundant.

 

On reflection I can't help but think that tools change so often and are often deprecated anyway, that this whole thing is a feature in search of problems, or something only those *constantly* making new projects would ever find use for.

Now if you're constantly making projects, 9 times out of 10 you're Unity staff. As a bloke making a game, I find my visits to package manager are probably going to end up being once a month.

I get a hobbyist would probably make a fair few projects, but in the end, I still do not see the value of feature sets, after a period of reflection. For feature sets, to exist, it should be at least be addressing a problem that's encountered enough for it to be a pain point to begin with.

Also, I *really* dislike the rabbit hole it encourages Unity's decision making to go in terms of "ah we don't need to make this compatible, feature sets will deal with it".

And what happens if you have a feature set, but half of them are missing because they don't support your version of Unity? It's a strange place to be. Maybe tags are an alternative consideration?

 

If its easy to make custom sets it would solve a painpoint for me, that is sorting my purchased assetstore packages

 

Yeah but wouldn't tags solve that, and such metadata could be imported from assetstore automatically. It's a problem that could be solved better with a different solution.

And I'm getting slight warning bells that this particular solution is heading this way purely because the UI is like this.

BTW I'm not invested much in this, it's hardly solving famine or world peace but it's still an interesting puzzle.

 

Yes being able to add tags inside the package manager would go a long way for me, now its only possible online making it less convent.

 

How long would it take for devs to make a button in package manager for opening manifest file? I'm begging for this for years already

 

Would absolutely love if we could build our own feature sets. Being able to setup a feature build for e.g. prototype project that includes stuff like URP, Input System and some of my own packages would be awesome!

 

bump on this

 

Can we make our own feature sets in scoped registries?