Feature Request: Package source git

[jouni-kantola]

To ease the process of publishing new packages, it would be good to be able to reference git repos as source for NuGet packages. With npm you can target a published tag/version (https://docs.npmjs.com/files/package.json#git-urls-as-dependencies). This could then also be used to in a CI process to build referenced packages.

[yishaigalatzer]

We currently are in the camp of packages are immutable and should work in environments where there is no internet access (ala behind firewall, closed networks). So we are unlikely to take this in.

I'm moving this item to the discussions milestone rather than immediately closing to facilitate some more discussion on it.

CC @davidfowl

[csharpfritz]

Lets make sure we understand the request is to support git endpoints, and those could be hosted on other providers besides Github, bitbucket, and VSTS.

I don't see much difference between a Git endpoint and a network folder endpoint.

On Dec 10, 2015, at 12:38, Yishai Galatzer notifications@github.com wrote:

We currently are in the camp of packages are immutable and should work in environments where there is no internet access (ala behind firewall, closed networks). So we are unlikely to take this in.

I'm moving this item to the discussions milestone rather than immediately closing to facilitate some more discussion on it.

CC @davidfowl

—
Reply to this email directly or view it on GitHub.

[jouni-kantola]

As @csharpfritz already commented, git can be hosted within local networks. Though, in my opinion, the package should be possible to access from any URL/endpoint.

A concrete example of what is requested is to push a tag, and reference it in packages.config like this:
<package id="MyPackage" targetFramework="net46" src="git+ssh://url.git#v0.0.1" />

[jouni-kantola]

Also, since we'd be refering a git tag/release, I'd say that supports the path of immutable packages.

[yishaigalatzer]

It's not exactly immutable, but this is different than what I envisioned you initially asked.

A user can make that choice (rather then what I thought is a package author sharing packages on nuget.org)

[csharpfritz]

What Yishai is highlighting is that you can 'bait-and-switch' with a "git
push --force"

Other tools solve this by storing a hash of what was originally fetched to
ensure it isn't changed in a restore. Its a solvable problem...

Jeff

On Thu, Dec 10, 2015 at 1:23 PM, Jouni Kantola notifications@github.com
wrote:

Also, since we're refering to a git tag/release, I'd say that supports the
path of immutable packages.

—
Reply to this email directly or view it on GitHub
#1822 (comment).

[yishaigalatzer]

This seems like a feature that can work reasonably well for project.json scenarios (where installing a package doesn't modify the project), with packages.config it could work as well, but will require interesting thought around updates and package versioning.

This also seems closely coupled to your other idea of providing a link to a file path #1821, with similar pros/cons (other than of course supporting git from within nuget).

So I'm going to merge the two, and we can discuss them in one go.

For reference the suggestion in #1821

is to <package id="MyPackage" targetFramework="net46" src="\\network\pathtopackage" />
or to <package id="MyPackage" targetFramework="net46" src="/pathToFile" />
or to <package id="MyPackage" targetFramework="net46" src="c:\pathToFile" />

[yishaigalatzer]

So some more thinking in this area - The issue with specifying a direct source for a package does work, but is going to be a bit of an oddball. The two scenarios that I see not quite working

1. Dependencies - If you specify the package directly, it works if the package has no dependencies or the dependencies exist elsewhere. For packages.config that might be ok, because you add them all at once (but again you need a feed to find the dependencies). In project.json that wouldn't work at all unless you lift all the dependencies manually.
2. Updates - Since the package points at a direct download point, there is no way to figure out where the next version is (without adding a more specific tagging scheme, which will turn git into a tagging into a feed scheme ala bower)

Thinking out loud on an alternative - is to layout the packages in a git repo that looks like the structured packages here - http://blog.nuget.org/20150922/Accelerate-Package-Source.html, then make that git root as a feed. Initially cloning the feed would work, but we could even make feed protocol based on git to avoid having to clone the whole thing.

[jouni-kantola]

I guess it more or less sums up to being alternate and individual package sources.

A common workflow when building private npm modules is to first create a symlink to a package folder, which is then used as reference. Once the tag is pushed (a released version), the package is instead referenced by an URL to that specific tag.

[yishaigalatzer]

I'm trying to understand what doesn't work for you in the current nuget workflow:

1. Create a temporary package (typically versioned as pre-release)
2. Put it in a local folder
3. Add the folder to the local nuget.config file in the project folder
4. Build
5. Stabilize the package and push it to a public server (nuget.org or internal company server)
6. Use the public server feed in your project.

[jouni-kantola]

Using a local folder as NuGet source does definately solve feature request #1821.

What I'm looking for in this feature request is to be able to not using a NuGet feed at all, but instead using alternate package sources. We create one repo per NuGet package, which would be great to have as package source, since we get an easy workflow around versioning.

[yishaigalatzer]

So the goal is to piggy back on github instead of creating your own server? Or is there something else? NuGet already provides a pretty simple workflow for versioning, so I'm trying to understand if what is blocking you is the capability to easily push packages to a 3rd party (private or public) feed without having to invest in setting up a server?

[jouni-kantola]

Yeah, I'd guess you can call it piggy backing. As long as the wrapping git endpoints supports referencing to specific versions, I guess any git source could be used. Where I'm coming from it's GitHub, but I guess other git setups supports this as well.

We have private NuGet feeds already, so the investment has already been made. What we think is a pain is the versioning. With npm and git you do it in two commands:
npm version patch && git push --tags

[yishaigalatzer]

We (well a community member did) add a simple patch support for packing so you can pretty much do the same in NuGet (unless again I'm missing something)

NuGet Pack -Suffix beta1234
Then push the package to a server, you can also use a public offering like myget or VSO that provides private feeds

[rrelyea]

Closing this request as we need to focus on higher requested features. If this is still interesting, and interesting to more people, let's discuss.