Search Unity

Package Manager and External Repos with Source Control

Discussion in 'Package Manager' started by gumboots, Jun 21, 2021.

  1. gumboots

    gumboots

    Joined:
    May 24, 2011
    Posts:
    298
    Hi all,

    I’m wondering if it’s possible to include Package Manager and external git repos in Source Control? My main concern being if an external repo or (less likely, but still possible) a Unity-hosted package is removed, they become completely inaccessible to the project. In which case revisiting in a year or two to make updates would be impossible.

    Is there any way to have these packages present in the project folder somehow, for inclusion in version control?

    Thanks!
     
  2. firstuser

    firstuser

    Joined:
    May 5, 2016
    Posts:
    147
    fork the repo and use that instead?
     
  3. oscarAbraham

    oscarAbraham

    Joined:
    Jan 7, 2013
    Posts:
    431
    I'm not sure if you can have a package's content be part of your repo and also update as part of the normal flow. If the package itself is a git repo, maybe you can use git submodules? I personally don't like git submodules, but I'm the kind of person that prefers Github Desktop to the CLI, so your mileage may vary. If you're not using git for version control, I know that at least Plastic SCM supports connecting to git repos and using submodules; I haven't used it, but I imagine it's not too hard.

    If the packages are from Unity, I've seen a non-official mirror account in Github. I imagine those repos are legal to use because of the Companion License, but I'm not sure and, honestly, I personally wouldn't want to test that theory. I see no reason to ever worry about an officially released UPM being deleted with all its previous releases.

    Maybe a good alternative to submodules is using local packages. Packages can be forked and stored locally in their own repo. Then the same local repo can be used in multiple projects in the same machine. It can be a bit tricky to use with multiple people; there are two ways I know to handle that: Either every person agrees to use the same folder structure to store local packages relative to the project, or people that need to work in a particular package override the manifest.json to use a local version package, with a rule to never commit those types of changes to manifest.json.

    I'm thinking that, if your only concern is packages disappearing, maybe it wouldn't be too impractical to make a tool that checks the manifest, and forks the relevant packages every time it's needed? That way the normal workflow is not affected, but if in two years you want to update a project, and package is missing, you know there's a backup waiting to save you.

    I hope this wasn't too discouraging.
    Regards,
     
  4. The simplest way around this problem to move the package from the Library into the Packages folder. The downside is that you need to update it manually. But you can include it in your repo if you like and it works like the original package.
     
  5. oscarAbraham

    oscarAbraham

    Joined:
    Jan 7, 2013
    Posts:
    431
    Yeah, it's not a bad point. There's actually a method for that if one wants to automatize it. I'm not a fan of not only having to update the package manually, but not being able pull, merge or rebase local changes. The main reason I usually want to have a package locally is to change it. A friend of mine loves git submodules for this reason... Maybe they are not such a bad idea. I feel like I should say that submodules are the proper way to handle these issues, event though I kind of fear them.