Package Manager and assembly definitions

[metamorphling]

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: 1) Create core asmdef file in "Modules" folder 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. 2) Put scripts from "DOTweenPro" into "DOTweenPro/Scripts" and create pro asmdef file in Scripts For some reason if I created asmdef in DOTweenPro as is some strange errors were popping up, got the feeling asmdef was fighting dll. 3) Reference both core and pro asmdefs from source code

[Demigiant]

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, Daniele

[metamorphling]

It is highly recommended that you use assembly definition files for all the scripts in the Project, or not at all. Otherwise, the scripts that are not using assembly definition files always recompile every time an assembly definition file recompiles. This reduces the benefit of using assembly definition files.

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,

[laicasaane]

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.

[Demigiant]

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

[laicasaane]

@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 https://github.com/Demigiant/dotween/issues/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.

[metamorphling]

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 ;)

[Demigiant]

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

[Demigiant]

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.

[LittleBigMonkey]

So any news on this ?

[cg-adam]

Any updates on this? Would be great to have this as a package.

[Demigiant]

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 :|

[LittleBigMonkey]

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...

[Razenpok]

@mob-sakai made a couple of packages that are available via git https://github.com/mob-sakai/SoftMaskForUGUI https://github.com/mob-sakai/ParticleEffectForUGUI https://github.com/mob-sakai/UpmGitExtension

[Demigiant]

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.

[jasursadikov]

@Demigiant any news on this?

[Demigiant]

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 :|

[LittleBigMonkey]

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 :

• DoTween.Core
• DoTween.Modules.UI
• …

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.

[Demigiant]

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 :)

[laicasaane]

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.

[Demigiant]

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)

[laicasaane]

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.

[Demigiant]

I never really thought of implementing it with a "disabled Modules" option. I will think about it but it is kind of sad.

[laicasaane]

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.

[bdovaz]

@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 com.demigiant.dotween.ugui com.demigiant.dotween.physics ...

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.

[mschweitzer-sd]

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 :

• DoTween.Core
• DoTween.Modules.UI
• …

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.

@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 com.demigiant.dotween.ugui com.demigiant.dotween.physics ...

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).

[pshtif]

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.

[leon-arndt]

Huge DOTween fan, would love to use it as a package as well. Any update on this? Unity move towards packages seems to be clear.

[leandro-manifesto]

Seems like someone hijacked (maybe not intetionally) the DOTween package on OpenUPM: https://openupm.com/packages/com.demigiant.dotween/

[laicasaane]

@leandro-manifesto The problem is there is no way we can edit DOTweenSettings even if there is a copy in Resources folder

[Demigiant]

I don't know what the hijack means :B I've continued to make tests and discuss the issue with other devs (since by now I gave up hoping that UPM will get better and more dev-friendly) and I think I have a way (inspired from your suggestions of separating modules in packages), but it's a really complicated way that will take a while to be implemented and I'm giving priorities to other DOTween stuff first (like the Timeline, if you heard about it). I really have no timeframe for this. After I release the Timeline I will probably move to this though.

[edwonedwon]

Is this the latest news on Unity Package Manager support? I would love this!

[JimmyCushnie]

I too would really love this :)

[Zanleo]

Hi, I ran into a big need in Package for DoTween. Since a large number of internal developments are tied to DoTween and are delivered via PackageManager, but DoTween does not work from the package (

[edwonedwon]

I need this so much as well! I have several of my own packages that have dependencies on DOTween

[jansensevr]

We really need DoTween in UPM. We are currently working on dividing our project into smaller bits so the production team can more easily stay up to date with internal editor tools etc and ofc some of the editor code is dependent on DoTween. Since DoTween doesn't work when we put it in a package we cannot have any dependencies on it in our packages :/

Tomorrow I will try another solution as I believe we can manually wrap DoTween into an assembly definition and then reference that by name in the package. We will still need to manualy import DoTween into each project, but hey! it's still better than not having it at all. At least this modified version of DoTween can be wrapped into a UnityPackage and since we would reference the assemblydef by name from our packages, as far as I can tell, a simple unitypackage import should do the trick. Hope that works :)

[sicklydove]

Another +1 for this here. Big fan of DoTween, and have been using it for some functionality bundled up into a Package for a client. Unfortunately, I've had to remove it and reimplement my own basic Tweening with Unity's APIs, as this package cannot require any extra install steps. Would be really great to be able to use this.

[rhys-vdw]

I think I have a way (inspired from your suggestions of separating modules in packages)

I just wanted to add my thoughts to this thread (as I have here). You don't need to use multiple packages, you can have all the modules in the same package, but have each in its own asmdef which can be selectively imported into your project (and therefore included in your builds). I believe UniTask is probably the best reference for package architecture, it includes extensions that do not even compile unless its dependent packages are found (very cool, but not necessary for DOTween's packages). For example it includes a package of DOTween extensions that only compile if your project includes the aforementioned openUPM DOTween package.

[mikerochip]

Agree with @rhys-vdw, you can have a single upm package and split it into multiple asmdefs using the same strategy that was used to split the old DOTween modules. The upside is less packages to manage, but the downside is that it makes the Unity project itself bigger since the package will still download the source even if it's unused.

I think at this point whatever gets upm support faster is the right way to go.

[rhys-vdw]

The larger download is not a big deal, it's just a few text files and they don't even go in your project's version control. There are really no downsides and it means no more need for this custom module system and setup screen.

[emathis11]

Why not just use Version Defines (in the asmdef configuration)?

For example if the Unity built-in package "Physics2D" is installed (com.unity.modules.physics2d) it will define a compilation symbol such as "USE_PHYSICS_2D" that you can then use to wrap code that uses Physics2D, so that it is ignored if the user has disabled the Physics2D package.

The downside is that the user has to disable the whole Physics2D module in Unity instead of just the DoTween module. But this seems like the right approach with UPM.

[fwalker007]

Is there a solution for this anywhere? We really need this as well.

[rhys-vdw]

@fwalker007 what's the problem? I'm using the package on OpenUPM and it works okay.

[bdovaz]

@rhys-vdw in my case I can't change DOTweenSettings.asset via editor window. It freezes loading the data.

[rhys-vdw]

@bdovaz Yeah, I have the same thing but there are no negative consequences.

[bdovaz]

@rhys-vdw yes, we can still change this via global static settings.

[ExodusOTH]

Another +1 :) Whenever you get around to working on it, it'd be a big help to me too, I've grown to really like DOTween but I'm having to start shave away any dependencies not using the package system for my own personal toolkit

[lorinatzberger]

Any news on this? Moved to asmdefs and had a bunch of these problems. Assets\Plugins\Demigiant\DOTween\Modules\DOTweenModulePhysics.cs(188,65): error CS0411: The type arguments for method 'DOTween.To<T1, T2, TPlugOptions>(ABSTweenPlugin<T1, T2, TPlugOptions>, DOGetter<T1>, DOSetter<T1>, T2, float)' cannot be inferred from the usage. Try specifying the type arguments explicitly. Tried putting the dotween dlls in the assembly references by ticking the "Override references" in the assembly definition settings and it does not seem to do anything. This approach works fine with Odin which also has precompiled code. Quite a shame as I had to remove all references to DOTween for now. Luckily it was only 2 places since I didn't really get to the animate and make everything very pretty part.

[rhys-vdw]

@lorinatzberger The package on OpenUPM is massively out of date. I set up DOTween this week using the downloaded version. The main reason I had for using the package is to enable to UniTask extensions (which are disabled by default unless you have the package manager version included). My solution to this was copying the UniTask DOTween extension out into the main package.

@Demigiant would you be open to me opening a PR to support UPM? I have done this for ink-unity-integration and for my own package unity-destringer. I can't guarantee to deliver it immediately, but I am confident that I'd do a good job of it. Maybe in the next few weeks.

One potential blocker is that @yoshida190 has taken your namespace/package ID com.demigiant.dotween, despite not owning demigiant.com. Hoping they will respond here as they have issues disabled on their fork.

[lorinatzberger]

@rhys-vdw Even if it would be available on OpenUPM, I don't think that'll work with the pro version since then, there would be no reason to actually buy it. I'm talking about the latest version available in the asset store through "My assets" in the regular package manager.

[Razenpok]

@rhys-vdw

Regarding the taken package ID - I'm pretty sure you can just ask @favoyang (the creator of OpenUPM) to transfer the ownership if needed.