what is the use case of project/packages?

context menu is the same, I can't drop plugins in there so can't figure out how it's useful.

 

Packages folder are the packages installed from the PackageManager, they can be removed from your project if you go to the PackageManager window. Every time that you install a package from the PackageManager it will be installed there.

 

You can also create your own package of commonly used code across projects to avoid having it checked in along with the current project's version control.

 

I thought that's what it was for. I couldn't figure out the workflow, mind pointing me to the how to?

 

It's not super well-documented yet, I think, but here's what they have on making packages so far:
https://docs.unity3d.com/Packages/c...1.7/manual/index.html#advanced-package-topics

Rough outline of required steps:
-Create shared code in a Unity project or solution
-Check into VC
-Have check-ins trigger a manifest/package build script
-Stuff package contents in some accessible web server's hierarchy, using URLs generated in the manifest
-Add your custom package repository to project configurations to see packages

So a little convoluted. I'd like to make some server-side tools to make such customisation simpler when I have time. Maybe some continuous integration tools could be massaged into doing the job, and maybe some simple scripts will be sufficient.

I don't see anything about an archived single-file distribution method either (ZIP archive or tarball), so I dunno if they support it. Definitely a lot of things which could be more convenient, as downloading multiple files over the net takes longer than even downloading the same amount as one file.

 

@laurentlavigne,

In the future (somewhat currently), Package Manager will permit you to install assets, code, functionality, QoL items, (like .unitypackages from the Asset Store currently do). The case of having it being shown under the project browser comes from a few use cases:

• Some users expressed they wished to know what packages were compiled and built on the project. Basically, transparency...
• Eventually, there will be assets that will ship that users want to reference with the Asset Picker or through a drag-and-drop.

In the very near future, we are working on a few things that will change this behaviour. One of these will be hiding every package that cannot be referenced in a project and adding a visibility flag that allows the user to specify what level of visibility is adequate for him.

Cheers,
Pedro
Unity STE

 

I see the benefit of showing packages when I reuse code between projects, but... how do I do that currently, without jumping through the crazy hoops outlined by @orb ?
Also a hide packages option in the project menu would be good for most users (!some users).
Finally, shouldn't Jetbrain be under packages instead of being copied in every single project?

 

Hello again,

We worked on a feature recently that allows you to add a package from a git URL. We're working on the documentation of said feature. It's currently going through our internal flow and it's intended for internal use until we make sure there are not "kinks" in it. We will make sure that it's properly "advertised" so that users like yourself can take advantage of it.

Another way to accomplish this currently would be to create a package locally that contains the code you wish to share amongst projects. It needs a package.json file that should contain the following fields:

Code (CSharp):

1. {
2.   "name": "com.unity.my_package",
3.   "version": "0.0.1",
4.   "dependencies": {
5.   }
6. }

Once that package is created it can be referenced through the project manifest by adding something like this:

• MacOS

{

  "dependencies": {

    "my_local_package": "file:/Users/pascall/Packages/my_local_package"

  }

}

​

• Windows

{

  "dependencies": {

    "my_local_package": "file:C:/Users/pascall/Packages/my_local_package"

  }

}

​

None of this removes the steps that "make you jump through hoops", but it's a workaround until you can use git URL's.

As for "Hide Packages", it will be amongst the features of our visibility flag work we're currently undertaking.
For JetBrains, I don't know, perhaps we need to consider that option. I'll raise with the team.

Cheers @laurentlavigne,
Pedro
Unity STE

 

If it will work with GitHub and even self-hosted GitLab/GOGS it's going to be an improvement. I don't see a simple way around the hoops either, but all the big VC collaboration tools support webhooks, so you can make magical scripts fire off on check-in which increase build numbers (or grab version number from the latest tag) and whatever else you need to do to make it show as updated.

 

Just collapse the packages folder

 

You can launch it now, we're used to broken

Thanks for the useful comment, you genius

 

My point is you don't really need a checkbox to disable/revert every change Unity introduces. The dev's working on the new hierarchy prefab icons pointed out that every new configuration option added increased complexity, making it harder to maintain the software. They have to consider users who have the option turned off and on, and any combination of other configurables. I am not sure if you noticed but Unity has not been very stable as of late, and I rather the devs spend time focusing on what is really important rather than putting checkboxes to toggle every new change they make so you can keep your editor looking the same as it did for the last 5 years. Just collapse it if you aren't interested in seeing it and move on to working on your game.

 

Alright king obvious, point taken.

 

@Prodigga, @laurentlavigne,

I hear you when you state that "you're used to being broken" or that "Unity hasn't been very stable of late". These are things that we want to fix and I wish you could give me some feedback (you can send me a private DM if you wish) if you have the time. I'll make sure the feedback is sent to the right channels.

Thanks kindly,
Pedro
Unity STE

 

Thanks Pedro, truly appreciated on this end of the world!
And by broken I mean workflow broken, the editor is rock solid and most things released are rock solid, just super clunky.
So what I meant to say is: show us the goods before you've spent so much time that it causes you pain to change it.

By the way, why Github? Why not local folder?

 

Making it able to grab and maintain github or other source control urls would help deal with a lot of annoying issues with using open source packages for things like UniRx, or Zenject, or any number of other great utility libraries, most of which are hosted on github.

On top of this, it's not a far stretch to adapt the url checkout method for a company's internal source repo, helping to make things more modular and prevent the kinds of mishaps that can happen with git submodules (which are either "adequate" or "broken as heck" depending on who you ask).

 

When is this feature expected to be at least publicly available? I'm desperately looking for solution that avoids loading in packages via git submodules.

 

Hello all,

@laurentlavigne:

• Local folders are supported through the UI and manually through the project's manifest.json. There is "some" documentation available here: https://docs.unity3d.com/Packages/com.unity.package-manager-ui@2.0/manual/index.html#extpkg. I apologize, it is somewhat brief.

@laurentlavigne, @james7132:

• Feature is currently planned to be added to 2019.1. It will be accessible through the Package Manager UI. We are discussing the possibility of adding an in-between step in 2018.3. I'm glad we're working on features that you, our users, are waiting forward to use .

@recursive:

• Private registries is also part of what we want to support more fully. We're introducing scoped registries in 2019.1. This means that you can have more than one registry per project. As for .unitypackages, they will eventually also be digested through the same means. Currently, there is a dual method of distribution for two different formats of packages: Asset Store and Unity Package Manager. The ultimate goal is to merge both, unify the format and make everything seamless to the user.

Cheers,
Pedro
Unity STE

 

Not sure it's the feature I want. I will describe my feature request here and I think it's extremely important to improve workflow. I would like to see something like git url cache just like GI Cache that able to store all the inserted git urls that able to carry over not just every new project but every new Unity releases. Meaning that no matter I create a new project from Unity version A or B, it will read the same git url cache. This idea can further expand to another new feature that become read and parse file from internet instead of locally. The intention of this 2 features is to get list of Packages locally or over network.

 

Thanks for the feedback @optimise. I don't think we're planning on doing anything like a "git URL cache" but I could be wrong. To rephrase, in order to make sure I properly understand what you are asking:

• You want some form of git url cache persistence in order to improve the startup flow of Unity projects.
• You want support for personal network registries.

Is that what you're asking?

If that is what you're saying then scoped registries will allow you to point your second registry pretty much anywhere you want, in the network or locally, if your package is compatible with our format. On top of that, scoped registries allows you to specify where to look for packages by explicitly specifying something like this:

{

  "scopedRegistries": [

    {

      "name": "Development",

      "url": "[URL='https://api.bintray.com/npm/unity/unity-dev/']https://foo.unity.com/npm/unity/unity-staging"[/URL],

      "scopes": [

        "com.unity", "com.unity.2d.common"

      ]

    },

    {

      "name": "Production",

      "url": "[URL='https://api.bintray.com/npm/unity/unity-staging/']https://api.bintray.com/npm/unity/unity/"[/URL],

      "scopes": [

        "com.unity.2d"

      ]

    }

  ],

  "dependencies": {

    "com.unity.cinemachine": "1.0.0",

    "com.unity.2d.common": "1.0.0",

    "com.unity.2d.animation": "1.0.0",

    "com.my-company.package1": "1.0.0"

In the case above, Unity Package Manager would always look for com.unity.2d.common in "url": "https://foo.unity.com/npm/unity/unity-staging" instead of looking for it under Production.

Cheers,
Pedro
Unity STE

 

[+] Packages are json files, okay ... UnityPackage are self contained and easy to use, could you make the [+] compatible with UnityPackage?

 

Yep, @laurentlavigne, feedback noted!

Cheers,
Pedro
Unity STE

 

Thanks for the reply. It looks like what I want but does it Unity version independent when git package releases instead of like the current manifest.json that must set manually per project? Another question, what is format of scopedRegistries url? Seems like it has protocol instead of just get the json that has list of git urls.

 

Hello @optimise,

If you're asking if the git package will update automatically, the short immediate answer is no. The feature, for now, will be exclusively manual and will have a "lock" to a specific hash or version. We are currently designing the interaction in Package Manager UI.

The lock looks a bit like this:

Code (CSharp):

1. {
2.   ...
3.   "lock": {
4.     "com.unity.package-manager-ui": {
5.       "hash": "9e72f9d5a6a3dadc38d813d8399e1b0e86781a49",
6.       "ref": "v2.0.0"
7.     },
8.     ...
9.   }
10.   ...
11. }

You must delete it manually for it to refresh. You can also specify a revision or a hash to "lock" it to that particular revision.

It's a regular URL. The "inline code" option in the forums wraps it bizarrely.

Cheers,
Pedro
Unity STE

 

Hi

For now Packages is read only, it is somewhat ok for external packages and definitely not ok for local ones.

But even for external ones e.g. ProBuilder we need at last one directory inside package for local assets like settings, or any other assets that package can create implicitly.

For now ProBuilder create trash in Assets folder and if same behavior will be in every package we use in future than Assets folder will be full of trash that is not good thing.

@pedro_unity can you explain expected future behavior of packages?

 

Hi @Jes28,

Thanks for your post. Answers below:

We're thinking about how to make editor settings mapped to a specific YAML file readable by code. For runtime settings, is a bit more difficult but we're discussing internally about how to resolve this.

That is happening because of legacy reasons. Some of the files created by ProBuilder, TextMeshPro should go into the editor settings I discussed above.

Cheers,
Pedro
Unity STE

 

Hi @pedro_unity,

Thanks for answer.
You are speak about settings, but what about local assets?

For example Visual Scripting plugins or Shader Graphs all create intermediate assets as a source of actual script or shader and most of the times We dont want these intermediate assets to clutter assets folder. So best option is to keep it inside package local assets.

Some plugins can create variations of their assets dynamically and there is no place for this variation in Assets directory,
I think perfect place is Per Package local Project directory i.e. Packages/[PackageName]/LocalAssets.

Can you comment please?

 

Hello @Jes28

I understand. I'll pass along the suggestion you're making today.

Cheers,
Pedro
Unity STE

 

Thanks

 

TextMeshPro spams the project folder with assets, I'd rather have packages self contained as if they were editor resources and if I want to customize, I copy drag to my asset folder.

 

What is the intended workflow if you want to pull a package into your project so you can modify the source code?

I need to clean something up in TextMesh Pro, but I'm struggling a bit to bring the source code in without breaking all my GUIDs

Edit -
I've managed to workaround this like so -

1. install the package via the package manager.
2. move the package from Library/PackageCache to your Assets/folder
3. note that all the scripts in the package are probably set to read-only. you may want to set them to read/write if you intend to edit them.
4. Edit Packages/manifest.json - remove the entry for the package you installed. I think if you don't do this step, the package will get re-installed into your Library/PackageCache

A button in the package manager to automate this would be great. Bonus points if the imported package keeps some meta data about what package 'version' it originated from so we have a clean record to diff against should we need to.

 

Hi @chase-cc,

You're right, the way to do this is to embed said package and then do the changes you need. Thanks for the feedback, I'll discuss with the team.

Cheers,
Pedro
Unity STE

 

Hi @pedro_unity, I notice starting from Beta 7, experimental support for Git package feature has been added. How can I setup Git package?

 

Check this thread, where this is discussed https://forum.unity.com/threads/git-support-on-package-manager.573673/