better asset distribution (use github releases, and unity packagemanager)

[dbrizov]

better asset distribution (use github releases, and unity packagemanager)

[soraphis]

The assembly definitions are for people with 2018.3+. Older versions of Unity don't support it

2017.3 was the first version to use them. which means that 2017.4 LTS also supports them.

which means the only users that would have to manually move them into the plugins folder (if they want that) would be 5.6 users.

[dbrizov]

Just added support for UPM. Here is the entry in the manifest

"com.dbrizov.naughtyattributes": "https://github.com/dbrizov/NaughtyAttributes.git#upm"

[dbrizov]

Thanks, I'll check it out

…

On Mon, Mar 18, 2019, 00:33 Oliver Biwer ***@***.***> wrote: Just a few suggestions: Unity 2018.3 supports including packages via packagemanager from git repositorys. - Refactor the repository such that Assets/* is your root - add a package.json for integration with the package manager. see unity-atoms for reference: https://github.com/AdamRamberg/unity-atoms/tree/v1.0.0 for more info about that see the issue to those changes unity-atoms/unity-atoms#13 <unity-atoms/unity-atoms#13> ------------------------------ the *.unitypackage file should be an "realese" here on github. so users could simply download the package, instead the whole project and then using the package. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#49>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADc69S_dWh51ARGMZre7-c_uiJrUVz4cks5vXsK8gaJpZM4b4sHi> .

[MostHated]

Just a few suggestions:

Unity 2018.3 supports including packages via packagemanager from git repositorys.

• Refactor the repository such that Assets/* is your root
• add a package.json for integration with the package manager.

see unity-atoms for reference: https://github.com/AdamRamberg/unity-atoms/tree/v1.0.0
for more info about that see the issue to those changes AdamRamberg/unity-atoms#13

the *.unitypackage file should be an "realese" here on github. so users could simply download the package, instead the whole project and then using the package.

I don't necessarily agree. When I am going around and testing out new things I typically prefer to download the whole project because then I just hit Clone repo on the page, Github Desktop downloads everything, I can then just go to Open within Unity hub and go to that folder and open it, it will automatically select the appropriate version and necessary packages for me to test something out without having to first create my own project, hope/guess that I am using a compatible version, I install any correct packages, etc. I believe it is good to have all of the above options. If I download the project and determine that I like it, it would be nice to then, going forward, be able to just download a Unity package, or add it to the package manager, etc.

[soraphis]

If I download the project and determine that I like it, it would be nice to then, going forward, be able to just download a Unity package, or add it to the package manager, etc.

well, for the usage of the unity package manager a specific folder-structure is needed (or advisable).

there is no sense putting the *.unitypackage file into the repository instead of putting it into release. its even the other way: the *.unitypackage file is (basically) the same as the zip-downloaded project, so if you download the project, you already have whats inside the package-file. for users who only want the newest package file, there is no gain.

it will automatically select the appropriate version and necessary packages for me to test something out without having to first create my own project,

while i have no solution for this, tools like naughtyattributes should be compatible with a wide range of unity versions, so that this is not really a point for this project.

i personally have one project where i check out all the packages i'm interested. (i ususally put them manually or by *.unitypackage files into the project). I've already more than enough unity projects, it would drive me crazy to create for each project i wanna check out a new one.

I would not suggest the package-manager implementation if this tool wouldn't be such a library project.

[dbrizov]

You know you can just click on the package file and download it right? You don't have to download the whole repo. Another reason I want the package to be in the Plugins folder is that it's in a separate assembly and it doesn't recompile every time. I've also added assembly definitions for version 2018.3 and above.

[soraphis]

You know you can just click on the package file and download it right? You don't have to download the whole repo.

The file has no purpose in the git project. if i clone with git i cannot exclude it. whats the point of including zipped (the unitypackage is a zip) build files into the repository? its not the point of git, but its totally the point of the releases github feature.

Another reason I want the package to be in the Plugins folder is that it's in a separate assembly and it doesn't recompile every time. I've also added assembly definitions for version 2018.3 and above.

since you added assembly definitions it does not matter anymore that its in the plugins folder. but on the other side: you have all the examples in the plugins folder too! (they don't belong there)

---

well, i made a fork of this project for everyone thats wanna use the package manager. https://github.com/soraphis/NaughtyAttributes

[dbrizov]

Yeap, you are right. I will move the .package to a release. I am just wondering if the project structure can remain in the Plugins folder when I integrate it with the package manager. I will look into it :)

[dbrizov]

Btw, the project can also be downloaded from the Asset Store. I need to update the README.

[soraphis]

I am just wondering if the project structure can remain in the Plugins folder when I integrate it with the package manager.

But wheres the point? they have their own assembly definitions. The Plugins folder only has a special meaning if its under Assets. else its only a regular folder named "Plugins"

[dbrizov]

The assembly definitions are for people with 2018.3+. Older versions of Unity don't support it

…

On Tue, Mar 19, 2019, 00:41 Oliver Biwer ***@***.***> wrote: I am just wondering if the project structure can remain in the Plugins folder when I integrate it with the package manager. But wheres the point? they have their own assembly definitions. The Plugins folder only has a special meaning if its under Assets. else its only a regular folder named "Plugins" — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#49 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADc69YruY-Hq04hrmmbQkebxEUDXyRTJks5vYBYKgaJpZM4b4sHi> .

[dbrizov]

Just wanna say that the fact that the Assets folder needs to become the repo root is amazingly stupid. Next time I check-out my repo I need to create an empty unity project and move the assets folder inside it.

[soraphis]

this is more the problem of using a git repository as package source.

if you look at the scriptable render pipeline repository, you can see that they have multiple packages in this one git repostiory. they use a build script to add the packages to their npm repository which the package manager is using. so its absolutely possible to use subfolders as packages, but its by far easier to restructure the git repository.

Next time I check-out my repo I need to create an empty unity project and move the assets folder inside it.

which is a one-time setup step.

[dbrizov]

if you look at the scriptable render pipeline repository, you can see that they have multiple packages in this one git repostiory. they use a build script to add the packages to their npm repository which the package manager is using. so its absolutely possible to use subfolders as packages, but its by far easier to restructure the git repository.

I will investigate that. Thank you.

As for the one-time setup - it's really not that big of a deal, but me personally these kinds of things bugs me.

[soraphis]

I will investigate that. Thank you.

since you can't put it into unity's npm repository there is nothing really you can do about it. at least in its current state the easiest thing for us 3rd party creators is to make the git repository equal to the package repository