Search Unity

Feedback Feedback on creating custom packages

Discussion in 'Package Manager' started by Baste, Sep 18, 2019.

  1. Baste


    Jan 24, 2013
    I just got kicked into converting one of my old utilities I had put on Github into a UPM package. You can see it here.

    The process was overall smooth, but there are some issues that could get ironed out:

    - When working on the package, I generally want to test it in some other project that has the project's github url as a dependency. So the workflow is:
    1: make change in source project
    2: commit, and push to github
    3: update the package on the test project, test the changes

    The problem here is that there's no good way to do 3. In order to have the package be redownloaded, I have to create a new version and update to that in the package manager in the test project. That's not really ideal for rapid development, especially when the package isn't live yet.
    So what I ended up doing was to remove and re-add the dependency to force a fresh download. I'd love it if I could force Unity to redownload a package directly in the package manager, for instances like this.

    - The Samples~ workflow isn't documented yet, after 8 months of it working. You could pretty much just copy-paste from here to here.

    - The ship has probably sailed, but why the hell are you using JSON for this? It's so. damn. fiddly. to get the commas right. I never manage to make a json file without at least a single syntax error. Unity's yaml-based, and that's so much easier to write.
    This will probably fix itself if you build a proper pipeline for building packages, but it's annoying to deal with.
    Ludiq, eelstork and fherbst like this.
  2. Adrian


    Apr 5, 2008
    - For testing packages, I prefer using local references, using either «file:path» or copying/linking the package folder to Packages. The second one has the advantage that you don't need to touch manifest.json, you can just add and remove the package folder to override and revert the original dependency.

    - I totally agree regarding the superiority of Yaml over Json. In case of the package manager, which talks to npm servers in the background, using Json is understandable (not so much for asmdef files, they really should've used Yaml there). Using an editor that understands Json makes it a bit easier, e.g. VSCode will point out any errors in your Json file while you are editing and you save yourself a roundtrip to Unity.
    samuelb_unity likes this.
  3. Favo-Yang


    Apr 4, 2011
    I created a dummy project as a wrapper, for testing environment and generating the meta files. Then clone the package into packages folder as a local package.

    If you commit the dummy project to another repo. Then you can use git submodule to checkout the package repo to packages folder, same as above.

    If you put whole unity project into repo. Then you need custom package script or perhaps publish the package folder to a branch using a github action. However I feel a bit verbose this way.
  4. samuelb_unity


    Unity Technologies

    Nov 13, 2017
    Hi @Baste

    Thank you for the great feedback. I have relayed this to the team and I can ensure you we are working on most of these issues.

    Except the JSON one, that ship has sailed! @Adrian is right, it has to do with our use of npm servers. If you need to manually edit a JSON file, we recommend a text editor like VSCode which has error detection, as @Adrian said. However, we are aiming to provide an in-editor experience for most package operations so that you won't have to touch JSON files, everything will be in the Inspector.
    is already supported but the project
    still has some features that require manual editing, it's true.

    The main issue which has been shared by other users is the fact that there isn't a great workflow yet for git package development inside a git-tracked Unity project. This is something that's still being worked out. As mentioned by @Adrian and @Favo-Yang, in terms of rapid iteration, you're probably best off with a local file dependency (see "Using the FILE protocol" here The problem with this is that you still want your project to point to a remote git URL so you'd end up switching between file paths and git URLs. Git submodules is perhaps the proper way to go about it (repo inside a repo) but this comes with its own learning curve. We'll let you know when we arrive on some better guidance and hopefully write some kind of "Working with git packages" section in the manual.

    As for the Samples, I will find out when they are being officially documented.