-
Notifications
You must be signed in to change notification settings - Fork 250
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: Package source git #1822
Comments
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 |
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.
|
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: |
Also, since we'd be refering a git tag/release, I'd say that supports the path of immutable packages. |
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) |
What Yishai is highlighting is that you can 'bait-and-switch' with a "git Other tools solve this by storing a hash of what was originally fetched to Jeff On Thu, Dec 10, 2015 at 1:23 PM, Jouni Kantola notifications@github.com
|
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 |
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
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. |
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. |
I'm trying to understand what doesn't work for you in the current nuget workflow:
|
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. |
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? |
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: |
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 |
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. |
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.
The text was updated successfully, but these errors were encountered: