UpmGitExtension
UpmGitExtension copied to clipboard
Could we have option for local clone?
In the scenario that we want to develop package while also make it work directly in other project. I think UPMgit should have an option to actually cloning the git repo into some local folder and add the local path to UPM instead of PackageCache
folder
Is it possible?
Hi @Thaina I understand what you mean. I will try it later. :)
@mob-sakai Thank you very much
I actually wish that this functionality should be default behaviour of official UPM. Because we should develop package in this way
If possible I wish that instead of an option, it should be default for UPMgit
@Thaina OK, you want to develop your package(s) within your project, right? (I assume it is a common package like a framework)
Do you want to develop a package without using a subtree (that is, without committing to the project repository)?
@mob-sakai That's right. I expect that the package should always be loosely couple with the project and other packages. So we should just specify only dependencies instead of subtree
I think this approach is more compatible with unity package system
@Thaina
- Is the project managed in a separate repository from the package?
- Is the project a product? Or is it a demo (sample)?
- Is the project included in the package as *.unitypackage file?
- Will the package be distributed as a *.unitypackage file?
@mob-sakai In my use case
-
Package is independent and could be reused in any project
-
Project just set dependency on package and is its own product, has its own repo separately and independently
-
Package will only be included as UPM reference. I expect that we will never use
uniypackage
anymore eternally
If you add a package directory to Packages
directory, the package will be installed in the project.
- It is given priority over
PackageCache
directory. - It can be edited.
- You can also add symbolic link as a package directory.
- Win:
mklink /D {dstDir} {srcDir}
- Mac:
ln -s {srcDir} {dstDir}
- Win:
~/repos/
- product_project/
- .git/
- Assets/
- Packages/
- manifest.json
- a_great_package/ ---> ~/repos/a_great_package/Packages/a_great_package/
- ProjectSettings/
- Library/
- ...
- a_great_package/
- .git/
- Assets/
- TestForPackage/
- test.scene
- Packages/
- manifest.json
- a_great_package/
- package.json
- a_great_package.asmdef
- a_great_package.cs
- ...
- ProjectSettings/
- Library/
- ...
@mob-sakai My point is, I want that process would be automatically done with the git package manager. Because it would be better when we could specified git URL in the package but also could edit it while working in project
Suppose I have 2 machines at work and at home or I have a friend that also collaborate to develop the same package, I could just configure the project with package's repo URL. And the manager will pull that URL directly into packages folder (or any local folder that we could work with). Then any of us could make change to package (separate from project) and push to repo of that packages with normal git process. Without the need to setup folder structure of each machine or pull package from git url manually
Hmm, is the package repository automatically pulled by this plugin?
For example, every 10 minutes?
@mob-sakai No, just when the manifest.json was changed by adding git url into it, or the project got opened, and the package repo was not pulled as local folder yet (also trigger if it in package cache but not in packages folder)
After it was pulled as local folder, we could fetch and pull to update by other means (such as vscode will auto fetch by itself)
- Local clone feature allows you to develop packages without commiting to the project repository.
- Select a package in UPM UI and press "Develop this package in local" button.
- The package repository will be cloned in any local directory (not in project directory).
- A symbolic link to the local directory will be generated in
Packages
directory.
- This feature does not automatically pull or fetch the cloned package repository.
- Only a few project members (eg. package engineers) will use this feature.
- This feature is not necessary for other members (artist, sound, planner, debugger, QA team, etc.) and CI/CD tools (Jenkins, UnityCloudBuild, etc.).
- The package is developed in the UPM directory structure, not the Unity project directory structure (that is, including the Assets directory, ProjectSettings directory, etc.).
- Or, the directory containing
package.json
andpackage.json.meta
with the same package name is the development directory
- Or, the directory containing
@Thaina How is that like this?
@mob-sakai That seem like exactly what I wish for
Maybe Develop this package in local
would be a toggle? And so it would keep remembering in the current machine and checking each time the project was opened or package changed. Also it could toggle off and get back into normal behaviour (also remove clone
button too maybe?)
A little suggestion that this feature might have 9 clone depths by default? (Actually could be any number, just think that it should not be more than 10)
ps. Do you have kofi or something that accept little funding but not a subscription?
Ah, only Paypal... [email protected]
Oh shit. Just want to send some gift but then it has a fee in the same amount of my sending. 😰😰😰
Oh... thank you for your support!
Or, the directory containing package.json and package.json.meta with the same package name is the development directory
I noticed this was a mistake. We should only checkout the revision referenced by the project. It contains UPM directory structure. Another revision (branche or tag) may be not equal to the package installed in the project. It may be newer or older. For example, if a package taged "1.3.1" is installed, we should checkout the same revision and modify it.
If you are using the subtree split strategy (in other words, if you are developing a package with Unity project directory structure), you will need to merge it into the developer branch after modifying the package.
@mob-sakai I think that's fine. We should always use UPM from now on instead of unity legacy structure
Sorry my late reply.
What you want is a feature like "npm link". It is used when developing local npm packages. Instead of downloading the package from the registry, it creates a symbolic link to the local package directory.
@mob-sakai Somehow similar but I'm not sure could UPM work in that way ?
For example:
Step 1: A member clones the project.
repos
└ the-project << CLONED
├ Assets
│ └ ***
├ Packages
│ └ manifest.json
└ ProjectSettings
└ ***
manifest.json
is as follows:
{
"dependencies": {
"package-a": "ssh://[email protected]/your_name/package-a.git#1.0.3",
...
},
"lock": {
"package-a": {
"hash": "79fa88282ae1233e4841d87fd256b80f13cd8b62",
"revision": "1.0.3"
},
...
}
}
Step 2: Toggle on Develop package-a in local
in package window.
Step 3: Package package-a
is cloned into the project's parent directory.
NOTE: If it already exists, it will be skipped.
repos
├ package-a << CLONED
│ ├ src
│ │ ├ ***.cs
│ │ └ ***.asmdef
│ ├ src.meta
│ ├ package.json
│ └ package.json.meta
│
└ the-project
├ Assets
│ └ ***
├ Packages
│ └ manifest.json
└ ProjectSettings
└ ***
Step 4: A symbolic link to package-a
is created in the Packages
directory.
repos
├ package-a
│ ├ src
│ │ ├ ***.cs
│ │ └ ***.asmdef
│ ├ src.meta
│ ├ package.json
│ └ package.json.meta
│
└ the-project
├ Assets
│ └ ***
├ Packages
│ ├ package-a -> repos/package-a << CREATED
│ └ manifest.json
└ ProjectSettings
└ ***
Step 5: Develop it as you like.
Step 6: If there is a new commit in the package-a
repository, update the lock
in manifest.json
{
"dependencies": {
"package-a": "ssh://[email protected]/your_name/package-a.git#1.0.3",
...
},
"lock": {
"package-a": {
"hash": "97d042ab994685c2687d539f125da1e6e6de9e2d", << CHANGED
"revision": "1.0.3"
},
...
}
}
Step 7: Toggle off Develop package-a in local
in package window.
Step 8: The symbolic link to package-a
will be removed in the Packages
directory.
NOTE: package-a directory will be not removed.
repos
├ package-a
│ ├ src
│ │ ├ ***.cs
│ │ └ ***.asmdef
│ ├ src.meta
│ ├ package.json
│ └ package.json.meta
│
└ the-project
├ Assets
│ └ ***
├ Packages << CHANGED
│ └ manifest.json
└ ProjectSettings
└ ***
It seems to work well...
I think this covered all we needed
I am ready to tackle this feature 👍
I assume this was never done/worked on?