I just updated my Unity from 2017.3.1f1 to 2018.2.1f1 and when I opened my project it moved the manifest.json file from the UnityPackageManager folder to the Packages folder. Also, it created a bunch of files and folders in the Packages folder.
My question is:
Is it safe to ignore the Packages folder from the repository, especially manifest.json?
Thanks.
manifest.json contains list of your dependencies(the packages you have used for your project). so if You clone your repository on a different machine, unity uses this list to download the required packages.
short answer: You should not put Packages in your .gitignore. It should be committed along with the rest of your project files.
Not a lot of google results for this, so for future searchers I will add:
It seems in Unity 2020.1 (and probably earlier) that the actual package contents are held in Library/PackageCache, and only the manifest file lives in the root Packages folder.
If Library is ignored as it should be, then there is no additional entry needed in the .gitignore.
Related
I couldn't find a question that similar to mine but the point I'm asking is where do I run git init? Do I run it in the src folder where my code is or in the project folder which contain the src folder and a bin folder? I'm working with eclipse and gitBash. Hope this is enough info.
What do you mean by builded project? Are you referring to .classpath, .project, .settings
When you create a repo, you need to include anything needed to actually build the project.
That include the src/ folder, but also other configuration files.
Those can include the .project (if it has only relative paths, easily reused by others), and the .classpath: see ".classpath and .project - check into version control or not?".
The settings/ folder can also be included 5see "Which eclipse files belong under Version Control", but not the .metadata/ subfolder.
It even can include settings for other IDEs like IntelliJ IDEA, if other contributors are using that tool.
It would not include the bin/ folder, typically added in a .gitignore, because its content is regenerated on demand (built).
Run it in the Project folder.
src folder contains the code files mostly. But supporting resources may be included in the other folders. And you will need to add everything to git without which project may have problem running.
When we do "yo webapp" (assuming webapp generator is installed), it scaffold projects which contains file relevant to bower, grunt and then there is app folder, which we all know what's it about.
My question is, out of this structure what are the files that needs to be maintained in SCM, Should it be only app directory or should it whole structure ?(assuming there are no additional grunt task or any build file changes from earlier scaffolding)
Yeoman webapp generator will produce a .gitignore file which includes files that should not be committed to a SCM. This file includes the following directories:
node_modules
dist
.tmp
.sass-cache
bower_components
test/bower_components
It is clear that .tmp and .sass-cache have no reason to be in the repo as they both are only temporary.
There is however a discussion whether bower (and rarely node) dependencies should be checked in. For most projects I recommend not to.
Please note that in either case one should never change the packages directly in the bower_components or node_modules folder as any change will be lost at next bower install or npm install. A fork of the original project (either as a independent repo or to folder in the project - e.g. lib) is a better idea - a follow up pull request would then add a lot of karma :)
The dist folder with the build of the application may be committed depending on your deployment method. There is a very good guide on deployment on Yeoman site.
As a start, you should put everything into SCM with the exception of app/bower_components, test/bower_components and node_modules. All files under these directories come from public repo, either node or bower repo.
In this setup, whenever another developer checkout from SCM, he needs to run 2 commands: npm install and bower install. What I typically do is I create a file called install.sh (install.bat on Windows) and have these 2 commands inside this script file. In this way, when you find that you need to run more commands for initialization, you can easily add to this script file and new developers can just checkout and run install.sh.
In some cases, I found that I need to perform small modification to a public library. In this case, I will check this library inside bower_components into SCM as well. This is not common, but it happens.
I created a nuget package (let's name it Web.Content) with lots of js, css and other content for my other package (named Web). In nuspec file I had file section
<file src="Content\**\*.*" target="content\Content" />
I made changes in some files from Content folder, then I created a new version of Web.Content package.
I have a project that includes Web and Web.Content packages. After a new version of Web.Content package was created I updated it in my project via nuget. When I try to commit changes of my project, SVN suggests me to commit all content of Web.Comment package.
As I understand, when nuget package was updated all target folder "content\Content" was deleted and copied from package again.
But I need SVN to trace only changes that were made in a couple of files, I don't want to see thousands of changed files because actually changes were made only in some of them.
How can I make nuget copy only changed files? Should I change my nuspec file or should I create some PS script for my package that will override delete'n'copy nuget package update behaviour?
It will be great to have some examples or links.
Tried with NuGet 2.6.40627.9000 and Tortoise SVN 1.7.7.
As far as I understand NuGet copies files during package installation using somу VS API. This API makes SVN think that the file was deleted and a new file was added(probably this happened because VisualSVN or AnkhSVN is installed).
So we decided to do the next steps:
Place our content items in our own folder which name differs from
"Content"(let's name it "fs_content") because the presence of such
folder in package triggers NuGet usual installation behavior, but
we don't need NuGet to install our content in usual way.
Write own install.ps1 script that copies our content files to
destination and put it into Tools package folder.
But after installing such package our content items did not appear where they should appear. My colleague googled some information in NuGet help - "The package must have files in the content or lib folder for Install.ps1 to run. Just having something in the tools folder will not kick this off." We placed a dummy file into "Content" folder and Install.ps1 script began to copy our content from "fs_content" folder as we want.
Now SVN determines only changes made in some files correctly.
i understand that nuget's package restore downloads and 'installs' the various required packages before building a project. but i can't work out what purpose this actually serves.
as far as i can tell, the 'installation' of a package during the package restore, isn't the same as a package's actual installation - for example, if you do the following:
install the jQuery package (NOTE that this adds jQuery script files to your project's 'Scripts' directory)
delete the added jQuery script files
delete the 'packages' directory (steps 2 & 3 simulate the state on a build machine, or other dev's machine)
do a build (triggering a package restore)
at this point the build states
2> Successfully installed 'jQuery 1.9.1'.
however, the jQuery package's script files are NOT added to the 'Scripts' folder, and the files are NOT added to the project.
this means that you have to check these files into source control anyway.
which also means that when you update this package, you have to manage adding/removing the new/old files (since different, versioned filenames are used). otherwise your 'Scripts' folder fills up with an endless history of versioned script files.
so, if you have to check everything in anyway, and you have to manually manage adding and removing files when updating, what exactly is the benefit of restoring the package on build? what purpose does this serve?
more to the point, why doesn't this serve the obvious purpose: automatically adding the package's files to the project?
Using NuGet Without Committing Packages to Source Control discusses the reason behind package restore.
Package restore means you do not have to check the packages folder into source control. Once enabled for your project it will download the packages and put them back into the packages folder at build time if they are missing. It will not, as you have found, add any package files to your project. In the case of jQuery all the files from the NuGet package are added to your project. Other NuGet packages however include one or more binary files.
How do I create a solution-level NuGet package. That is, one that does not touch any projects, and is listed in .nuget\packages.config (not in any project-level packages.config files).
For example, psake and RavenDB.Server are solution-level NuGet packages.
I can't find anything in the docs for .nuspec files or nuget.exe that says anything about solution-level packages. I can't find anything special in the build processes of those two projects when they call nuget pack. In fact, I can't find a single search result at all about creating solution-level packages.
I found a brief comment from Phil Haack. It's from an issue on CodePlex:
We already support this. Just don't put any content in the /Content
folder nor in the /Lib folder. If your package only has contents in
the /Tools folder, the package will not get installed in the project.
Haven't had a chance to test this out, but it sounds like what you're looking for. A quick peek into the RavenDB.Server package (rename .nupkg to .zip) reveals a setup that is consistent with what Phil said in his comment. No content folder, no lib folder. Lots of files. The files are not in a /tools folder, so I think it's safe to presume that's not a requirement.