Package Manager and assembly definitions #251
Comments
|
Ahoy! Thanks a lot for the investigation on the matter: I will keep these info as a precious reference :) I'm waiting for Unity 2018.3 which will finally make the package manager available to everyone, and then I'll implement it for sure. Cheers, |
Important point, to support both methods it would be cool to have a checkbox in settings menu. Like, "Use Assembly Definitions". Since .asmdef files are plain text files, they can be generated and deleted with ease, |
|
I'm maintaining a multiple projects setup that has a copy of DOTween in each sub project just because of the utility panel problem. So I hope this feature would be done the sooner the better. No pushing from me, though, just hope so. |
|
I plan to finally experiment with asmdef today, but not on Package Manager to be honest :B It still seems very alpha so I'm verging on the side of "let's postpone that more". @laicasaane can you explain me more? I'm not sure I understood everything of the setup and of the problem there :B |
|
@Demigiant My project has been divided into 3 sub projects inside it, 1st is the core, 2nd is for the players, 3rd is for the content makers. All of them use DOTween and other libraries. Others can be made into local packages just fine, but DOTween couldn't. Actually I had reported that issue here #238 I know there wouldn't be any issue in runtime, and this only affects the Unity editor. But I really don't like errors and exceptions appear even in the editor, so I've to put a copy of DOTween in each sub project to avoid this exception. |
|
I too had some problems trying to isolate dotween into a package for multiple projects environment. Don't have a playground at hand, but if I remember correctly the cause of the problem was something like hardcoded paths for some elements of the plugin. As in, trying to access files(settings or editor images?) from the "Assets/smthsmth" while real path for package is under "Packages/PackageName/Assets/smthsmth". Setting paths to resolve for Assets and Packages respectively, depending on if dotween integrated or plugged with project, should solve the issue. Another possibility of what might go wrong is Resources.Load api, since if there are a few packages/projects with same files it does not differentiate of what to use and things may go wrong. I feel like this is actually a common problem for plugin makers this days. Unity is halfway onto breaking engine parts into packages, while some users are jumping ship and divide environment too. At this point I can only advice this approach to those who do not use plugins, have no plans to add them midway(which is hard to anticipate) or use them selectively - only tested and confirmed stuff. Meanwhile, let's hope DOTween will be able to support new approach sooner than later ;) |
|
Ah! Thank you both for the info. I was going to post a new version with auto-asmdef creation which I just finished, but after reading what you wrote I'm going to try and at least implement a way to find DOTweenSettings in any folder, so even if I don't do Package Manager myself it should work for you. Back in a short while, I hope :P |
|
Ok I created an external DOTween package and tried until now to make it work, but I finally had to ragequit :B I managed to get all references correctly, but the problem is that I also need to modify files via the editor, and it's a complete mess. I experimented but the lack of documentation is too great, so I'll postpone this for the day Unity decides to make Package Manager a little more open, sigh :| In the meantime, here's v1.2.225, where I added a button in DOTween Utility Panel to create the asmdef files. It creates one for the modules and one for DOTweenPro loose scripts (if present). I managed to create DOTweenPro's directly in the DOTweenPro folder by manually adding references to the asmdef json when it's created. |
|
So any news on this ? |
|
Any updates on this? Would be great to have this as a package. |
|
Ahoy! The documentation remains too intricate (for the things I need to do with DOTween), so until Unity officially allows the implementation of external packages with at least some API I'm postponing this :| |
|
Hi ! I'm using Git packages for most plugin I use in every project. It's sooo useful and easier to maintain. It's not too hard to use, you should look at it to make your plugin compatible. It would be awesome to not import it in every single project... |
|
@mob-sakai made a couple of packages that are available via git |
|
Mhmm ok you're convincing me to give this another try :P But I already know this will require quite a lot of time (I'll have to change the editor initialization logic of DOTween and other systems). I'm in crunch right now so I'll see if I can start working on this by the middle of next week. |
|
@Demigiant any news on this? |
|
I come back to it now and then, but always encounter new problems (see last one here). I definitely intend to work more on it but too much of DOTween is mutable and built with the options you choose via DOTween Utility Panel's modules, so it doesn't seem a good fit for the Package Manager. The alternative would be to make it less mutable like it was before, but I think that is a much greater advantage than PM. Sooo, in short, for now there's no date for when this might happen, and it might not happen :| |
|
I don't know why someone would desactivate basic unity modules. The only one I don't care, is 2D Toolkit. But anyway, instead of having one package that is mutable, why don't you try to have multiple package and include them in the package manager when needed. You could have something like :
That's how unity manage their own modules in the packages manager. And we can simply activate/desactivate a module by adding/removing a line in the manifest. Moreover, you can specify which revision you want if you need to support multiple unity version. |
|
The separation into basic Unity modules was a feature that required a lot of work, which I added after some users asked it :B It's rather important because if, for example, you have no Physics in your game and no script referring it then Unity doesn't include the Physics system in builds, so it helps making builds slimmer by removing stuff you're not using. The multiple packages idea sounds neat, I'm going to try that out :) |
|
I've deployed a customized repo so I can use DOTween with Unity package management system. And it's working almost fine so far. The only thing broken is DOTween Utility Panel. The panel won't show, and the DOTweenSettings.asset is read-only. At the moment, this is my strategy to solve that problem: edit the settings within an empty project, then copy that settings asset file over the main project.
Really hope to use DOTween via UPM officially one day. |
|
Sadly it's even more complicated than that. The Modules system changes actual DOTween files, so even if that would work it would overwrite all Modules-based DOTween scripts for all projects using the package, which is not nice :| I hope one day to give this more time (because it's gonna be a long and major refactoring) but I'm prioritizing other things for now (like a DOTweenTimeline which I've been working on for the last months :P) |
|
Beside that feature you are working on, could you prioritize making the settings accessible no matter where it is? IMO this is the only problem urgently needs to be fixed. The modules system could wait. |
|
I never really thought of implementing it with a "disabled Modules" option. I will think about it but it is kind of sad. |
|
For the time being, I think you should let all modules turned on by default, and let people know that if we use DOTween as a package we won't be able to turn off those modules, and that should be the limitation at this point. I think since all modules are on by default, only in some rare cases people will run into any problem and have to import DOTween directly into their project. This behaviour is more relax than the current one: the settings that is not editable directly in the project is really annoying. |
|
@Demigiant If you implement UPM you could resolve this better. Check UniTask repo on how implement UPM support: https://github.com/Cysharp/UniTask#upm-package Then you could separate in more packages. com.demigiant.dotween And we would use the packages we want. Regarding DOTween *.asmdef support I have a problem and is that if I enabled it it would generate a different *.meta with a different GUID. I have my packages depending on DOTween by GUID so in different projects your *.asmdef GUID is different and it brokes our references. |
+1 to both of these suggestions. TBH it feels like users asked for the DOTween modules approach because it was basically a workaround for the lack of a proper package management solution. Now that upm exists, I think the DOTween modules implementation is no longer necessary and should be replaced with separate packages that depend on a core package. Users can then decide via the package manager which modules they want. It seems like the main blocker is the fact that specific ScriptableObjects are assumed to be in specific locations in a project. I think this is generally a risky approach since it makes lots of assumptions about project layout. A suggestion I have is to invert the dependencies - either pass in references to the ScriptableObjects when you need them, save them off as properties so they can be set independently, or provide callbacks to let the user supply the objects. As far as the utility panel, maybe you just don't show anything until the user drags in or provides a location for the Settings object. I know that this would be a major refactoring, but it's worth it. upm is here to stay and all of Unity's engine components are being converted to use it. I think the comments blaming Unity for lacking documentation are unfair honestly. The documentation is quite good IMO and lots of plugins are starting to refactor to support upm (NaughtyAttributes, Deform, etc). |
|
We are just in the middle of packaging all our plugins and modules through UPM as well and actually the only 3rd party asset that can't be used through UPM seems to be DOTween. At this moment it can get so critical we will be probably looking to implement our own tweening library rather than using DOTween the old fashioned way, which in a big company was clunky to begin with. So we are welcoming Unity's modular iniciative and UPM and hopefully DOTween can join the bandwagon. |
|
@Laumania it's off topic, but if you want nested dependencies they can be installed via OpenUPM. So you can still have your mod framework on OpenUPM and have your users install it, including its deps, using the openupm CLI tool. Or simply provide them a Unity project scaffold that includes git dependencies in its manifest.json. |
The problem is, it makes things a lot more complicated for users who wants to mod my game and I want that to be easy. So I have included it in my Mod Tools instead, which makes it MUCH easier for users to build mods. I only need the DOTween for the mod to build, it's not actually included in the mod, when mod is loaded up in the game its actually using the DOTween within the game. Sorry for off-topic :P |
|
Hello, |
|
Bump on any update, would be super useful :) |
|
Ahoy, I'm sorry but I never know how to answer this. In theory I would go for "maybeee", because every time I try to get to it I get derailed by doing other DOTween features (because everything needs to be perfect before this process), and then it gets postponed once again because I'm overloaded. As a secondary but important note, like @Laumania said you can totally redistribute DOTween with your projects/etc. (as long as you redistribute it "as-is"), so that should help in some cases in the meantime. |
Hi there, |
That's how older DOTween versions worked, but I really didn't like it so I made a major refactoring to auto-rewrite DOTween's files instead of a user's project defines. My philosophy is that a plugin/asset should strive to change a project as little as possible, and adding lots of defines (especially considering how cramped Unity's define box is, and that someone might have their own defines in there) felt way too intrusive to me 😬 |
|
The UPM package needs to be immutable. There is a way to create a UPM package with "module" dependent code compilation without using project defines.
I can imagine how splitting this library into multiple packages can be troublesome during the delivery and installation process. In the Unity Editor window for module management user could choose to
API to add and remove project packages. |
@Demigiant From the perspective of an advanced developer, this is no problem at all.
The purpose of this issue is to avoid polluting the main Assets folder. I can live with a bunch of compilation symbols. |
You misunderstood, importing a package has nothing to do with the Assets folder. |
|
I updated my previous comment with a better explanation of the idea. |
See how this works in section "Defining symbols based on project packages": Basically the DOTween module would just set a flag for its own compilation based on whether another module was included. This is how UniTask flags its DOTween support on. In DoTween's case it could set a flag for e.g. UNITY_UI etc. |
|
Sorry for barging into the discussion. Just chiming in with a few extra details. I don't think it it would be necessary to split the library into separate packages. I think it was mentioned previously, but by using assembly definitions and the "Define Constraints" feature along with the "Version Defines" to limit when the assembly is used, you would be able to create assemblies for every occasion or have conditional code in them. The "Version Defines" feature is used to define a preprocessor symbol based on an expression using the present version of a package or unity module, or unity itself. That symbol can then be used in the code with #if, or in "Define Constraints".
By doing this, it should be possible to remove the need to modify the source files, allowing the library to exist in an immutable package. It should also not be necessary to add any global defines. These assembly definition features are supported from Unity version 2019 (according to the documentation). BTW: I think if code is in a separate assembly, it will be stripped from builds if there are no references to it from an included scene, assets in the resources folder, or from other code that is not itself stripped. So I am thinking that maybe you don't have to worry so much about your library forcing Unity to include components that it otherwise wouldn't have. I am kind of assuming this though. |
|
@LarsBlaabjerg The need for separate packages is coming from the feature of enabling and disabling certain DOTween modules. Even with the help of version define list it would be impossible to toggle a module inside an immutable package. (In a case where all modules and a core lib are inside the same UPM package) |
But you can have several assembly definitions in the same package. True. If you need to be able to toggle available features at a whim, you would need to add global defines (which is a fine way to do it btw), but I don't understand the need to to. Why not juts let all the modules be available if the prerequisites are? |
|
You're right, I agree. 👍 |
|
Yes, what @LarsBlaabjerg suggests is the standard way of doing things. And, in fact, what I suggested in the comment before his. 😉 |
|
Yeah, I know @rhys-vdw . I just couldn't resist elaborating it a bit :-) |
|
Hi @Demigiant , I understand your concern regarding not wanted to change user project files. What you could do make it more clean is to create a auto-generated settings file Assets/dotween.rsp The Assets/dotween.rsp file has to be included either by referencing it: A. Either by it through Assets/csc.rsp reading Assets/csc.rsp it automatically included or B. Adding it in Project Settings / Player / Script Compilation / Scripting Define Symbols Just as with the other method. -- Pro: Simple to setup, only one file is written to and one setting is changed. Nothing is changed in the UPM package folder |
|
Any news @Demigiant? It will be almost a year since my original PR. Can I help you in any way? It's a bit frustrating to see all my work stopped for a year but I understand that everyone has their priorities 😅 |
|
@Demigiant I don't really understand why it's so hard on your part. This issue seems like an eternity, while I've been already developing and maintaining a bunch of UPM packages without problem. Truthfully, there are many compilation symbols in my project, defined either by me or by 3rd packages. But it's fine, because we have to declare them only once. But upgrading DOTween is a recurring task that begins getting into my nerves. I might seem stubborn about keeping the There is no way to stop Unity from generating I really hope this issue will be concluded in the near future. |
|
PR created in July 2022 @Demigiant friendly ping! This summer you have been active, I see several commits in DOTween and there are new releases in August of DOTween in the Asset Store. I mean, I'd like to know why you don't show up here. There are a lot of people waiting for my work to merge. I already said I help you with whatever you need. |
|
@bdovaz first of all sorry again, and thank you for being friendly even if this got delayed for a very annoying amount of time. I always plan to get to this but then postpone it for one reason or another, and don't know how to explain it so I hide. The reasons I work on other commits is that bugfixing is always my main priority, so if a bug comes out I try to jump on it asap regardless of the mess I'm in. Which is also one of the reasons I postpone your merge. After the times I tried to tackle this I know that, contrary to bugfixing and smaller quality additions which only require bursts of a few hours, I'll need at least two weeks, probably three, of constant involvement in order to do this, and those are not easy for me to find (and to be honest, when I did find them in the past I ended up working on other improvements, because admittedly I still don't see much value in this feature, so that's also my bad 👀). That said, let me try again. I won't have enough time until the half/end of November and then I had planned to finish working on a small game, but I'll postpone that and give precedence to this. It's in my calendar now 👀 |
|
FWIW, I also need this for the same dependency reasons. It seems I am far from alone on this. Perhaps it should be a higher priority given the community response. |
|
Year 2024, after 6 years I'm still expecting for this feature ( (And thanks for this awesome project, I'm a DOTween Pro user) |
|
Hi @Demigiant! Firstly, many thanks for the wonderful plugin. I am anticipating this feature as well. Is there any update on this? |
@Demigiant any news (almost a year from your response)? This PR has been stopped for 2 years with all the work it meant to me at the time.... Now the situation has also worsened because the temporary fork of https://github.com/yoshida190/dotween no longer exists and we have started to fail this manifest.json dependency in several projects: |
and others
Are there any plans for moving onto unity's new package management system and usage of assembly definitions? Nothing urgent here, just an enhancement idea.
Tried to move "Demigiant" into "Packages", added packages.json and registered it with manifest - so far works well. Utility Panel is dead though, probably it wants dotween folder to be at hardcoded place?
I'm sure you are really busy, but just for the record dropping a few links on what I am talking about
https://docs.unity3d.com/Packages/com.unity.package-manager-ui@1.7/manual/index.html
https://docs.unity3d.com/Manual/ScriptCompilationAssemblyDefinitionFiles.html
Besides utility panel, as to what I had to do to make assembly definitions work with DOTween:
Seeing how project went modular way, there is a potential to breakdown every module into it's own folder and give asmdef file for every folder. That way switching modules will be as easy as having a core asmdef which adds/removes references to module assembly definitions.
For some reason if I created asmdef in DOTweenPro as is some strange errors were popping up, got the feeling asmdef was fighting dll.
The text was updated successfully, but these errors were encountered: