Bug: The version on the Unity Asset Store is different than the Git and OpenUPM versions, and installs in a different folder

[Tichael]

Describe the bug When installing GOAP through the Unity Asset Store, the files are put inside the Assets folder, compared to when installing through Git or OpenUPM, which puts the files in Packages. They are also different, like the one in Packages are missing the demo files.

Is it normal?

Steps to Reproduce Install the GOAP package with the Unity Asset Store or Git or OpenUPM.

Expected behavior I would expect that installing using the Unity Asset Store would do the same as Git or OpenUPM, installing in the same location and having the same files.

Screenshots If installed through Unity Asset Store:

If installed through Git or OpenUPM:

Unity Version 2022.3.7f1

Unity.Collections Version 2.1.4

Package Version 2.1.11 (although the Git version is supposed to be 2.1.12, even if the package.json still says 2.1.11?)

[crashkonijn]

Hi there @Tichael!

Thanks for you bug report!

Unfortunately the difference between the unity asset store version and the one from git is not something I have control over. When using the Asset Store it is imported as an asset (aka they get imported into your own project). When using Git the project is imported as a package, which is a reference but not actually imported into your project files. This is how unity works unfortunately.

You are correct that the version number in the package.json is off, this is something I need to update manually (and is something I forget sometimes). I will try and see if this can be automated somehow.

As for the Unity Asset store version being behind, yes that happens. Unfortunately setting everything up correctly and then uploading to the Asset Store takes quite a bit of time, so it's not something I do with every minor release.

[Tichael]

I don't think you're entirely right because I am using a package from the Asset Store and it is stored in the Packages folder. But, you may not be able to change it because your package is already on the Asset Store. It may be a choice you have to make from the start or something. So it is possible, but you're probably not able to change it.

I have something else to propose then. Maybe you could also include the demos with the Git and the OpenUPM packages. Or if you can't store the demos directly in the package for any reason, you could also create a _Sample folder, which makes it available in the Package Manager window. I'm just proposing ideas to make the different packages more or less the same.

Anyway, I just started to use this package and it's pretty good. Thanks for everything!

[crashkonijn]

Thanks for your reply (and your kind words)!

Could you give me an example of a (free?) Asset from the Asset store that imports as a package? This would indeed be a much better option.

As for your suggestion including the demo's in the git version, unity does indeed allow for a Samples~ folder. I will try moving the demo to that.

[crashkonijn]

Hi again!

I've just had a look at moving the demo's to be included in the package when pulling it in through git, but I'm running into an issue.

Currently I have these requirements for the demo's:

• I need to run tests against them.
• I need them to be easily editable in a unity project.

Looking at the current git repository it is setup as following:

• Demo (This is a unity project, which includes the demo files. This also references the package content)
• Package. (This contains the actual GOAP content)

Right now I can simply git clone the project and open the demo unity project, this gives me everything I need to edit and maintain this package.

I could create a _Sample folder (or something similar) in the package folder, and this would be included in package folder when importing it through the package manager. The downside of this is that you have no control over the packages folder, and will always have the samples folder/content available in your project. For example when trying to include your own WanderGoal you will also have an option to import the demo version. You will be unable to remove these files.

I could also move the demo content to the Packages\Samples~ folder, as suggested by the unity docs. This will give you an option to include the demo files through the package manager. This would then import them into your project, after which you could always choose to remove them again. This option would be great for users of this project, but do void my own requirements I mentioned.

One way this could be tackled is to have some sort of pipeline step which could copy the files from the Demo unity project to the Package\Samples~ folder whenever something is merged to master.

[Tichael]

I unfortunately don't have any free examples of assets from the Asset Strore going to the Packages folder. But if that can help, I'm using the Agent Navigation package.

I also think going with a pipeline step is inevitable. It will allow more flexibility with your git setup vs the package pulled by Unity. This could also allow you to automatically update the version number, maybe? Although, I'm not sure if you can create a package for Unity to pull from git with a pipeline, since git pulls the file directly... Unless you want to duplicate the Demo files.

Maybe that could be a potential V3 refactor since moving the Demo would break your test. Doing breaking changes in a minor version is not recommended.

[crashkonijn]

I did find this, which is something I could try.

I have also found release-drafter, which is something that could help with figuring out versions automatically and create better change logs. I still have to find something that can automate upping the version in the package.json as well.

If I get a GitHub action to update the package.json version, that could possibly also be used to copy and commit the demo content.

[crashkonijn]

Quick update; I've been testing (in a private repo) to get a couple things running.

When a PR is created:

• It will auto-label the PR based on it's branch and commits. (For example feature, bug, docs etc)

When a PR to master is merged it will:

• Generate a release draft with release-drafter, this will figure out the next version based on the labels
• It will read the newly generated version and store that in the package.json
• It will update the install docs/readme to include the tag (this is something I don't currently do, but is better)

https://github.com/crashkonijn/GOAP.git?path=/Package#0.0.2

This probably means I'm going to introduce the develop branch as well. Multiple changes can accumulate there and when merged to master it will become a release.

Last thing I need to do is test copying the demo folders to Packages/Samples~, but that should be relatively minor compared to the above :)