Comments (15)
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.
from naughtyattributes.
Just added support for UPM. Here is the entry in the manifest
"com.dbrizov.naughtyattributes": "https://github.com/dbrizov/NaughtyAttributes.git#upm"
from naughtyattributes.
from naughtyattributes.
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#13the *.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.
from naughtyattributes.
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.
from naughtyattributes.
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.
from naughtyattributes.
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
from naughtyattributes.
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 :)
from naughtyattributes.
Btw, the project can also be downloaded from the Asset Store. I need to update the README.
from naughtyattributes.
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"
from naughtyattributes.
from naughtyattributes.
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.
from naughtyattributes.
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.
from naughtyattributes.
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.
from naughtyattributes.
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
from naughtyattributes.
Related Issues (20)
- "Target object is null" error spam every time I interact with an inspector that has a Canvas HOT 3
- Meta Attributes no longer work for seemingly no reason HOT 1
- [Bug] OnValueChanged with Arrays/Lists. HOT 1
- [Request] What about adding "RequiredType" validation attribute HOT 4
- Progress Bar Hidden Value HOT 1
- NaightyAttributes import affects to UI view even without using any attribute
- TypeDropdown Attribute HOT 6
- [Request] AnimatorState Attribute HOT 1
- [AllowNesting] won't find CustomPropertyDrawers... and how I fixed it. HOT 1
- [Bug] Error "Unsupported type Vector2f" when editing Vector2 value in inspector HOT 1
- [Request] Clicking a button on multiple objects only clicks one
- Using NaughtyAttributes hides inspector tools for custom audio filters (OnAudioFilterRead) HOT 1
- [BUG] [ShowIf] with [AllowNesting] doesn't work for String values if put after a [TextArea] attribute
- GC allocs for rendering HOT 1
- Many attributes do not work in Unity 2022.2+ HOT 13
- Can't add generic script on object HOT 1
- (bug) Excessive Spacing with the ShowIf/HideIf attributes in Nested Arrays HOT 1
- Boxgroups do not display background on List<T> types
- [Request] Foldouts and BoxGroups should give a List<T> type a bit of an indent for readability
- [Request] Add enum support to "EConditionOperator.And" and "EConditionOperator.Or"
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from naughtyattributes.