Skip to content
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

Closed
jouni-kantola opened this issue Dec 9, 2015 · 15 comments

Comments

@jouni-kantola
Copy link

@jouni-kantola jouni-kantola commented Dec 9, 2015

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

This comment has been minimized.

Copy link

@yishaigalatzer yishaigalatzer commented Dec 10, 2015

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

@yishaigalatzer yishaigalatzer added this to the Discussions milestone Dec 10, 2015
@csharpfritz

This comment has been minimized.

Copy link
Member

@csharpfritz csharpfritz commented Dec 10, 2015

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

This comment has been minimized.

Copy link
Author

@jouni-kantola jouni-kantola commented Dec 10, 2015

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

This comment has been minimized.

Copy link
Author

@jouni-kantola jouni-kantola commented Dec 10, 2015

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

@yishaigalatzer

This comment has been minimized.

Copy link

@yishaigalatzer yishaigalatzer commented Dec 10, 2015

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

This comment has been minimized.

Copy link
Member

@csharpfritz csharpfritz commented Dec 10, 2015

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 comment has been minimized.

Copy link

@yishaigalatzer yishaigalatzer commented Dec 10, 2015

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

This comment has been minimized.

Copy link

@yishaigalatzer yishaigalatzer commented Dec 10, 2015

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

This comment has been minimized.

Copy link
Author

@jouni-kantola jouni-kantola commented Dec 10, 2015

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

This comment has been minimized.

Copy link

@yishaigalatzer yishaigalatzer commented Dec 10, 2015

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

This comment has been minimized.

Copy link
Author

@jouni-kantola jouni-kantola commented Dec 10, 2015

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

This comment has been minimized.

Copy link

@yishaigalatzer yishaigalatzer commented Dec 10, 2015

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

This comment has been minimized.

Copy link
Author

@jouni-kantola jouni-kantola commented Dec 10, 2015

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

This comment has been minimized.

Copy link

@yishaigalatzer yishaigalatzer commented Dec 10, 2015

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

@harikmenon harikmenon modified the milestones: Discussions, Future Apr 19, 2016
@rrelyea rrelyea added the Type:Feature label Jun 9, 2016
@emgarten emgarten modified the milestones: Future-2, Backlog Nov 9, 2017
@emgarten emgarten added the Priority:2 label Nov 9, 2017
@rrelyea

This comment has been minimized.

Copy link
Contributor

@rrelyea rrelyea commented Nov 29, 2019

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.

@rrelyea rrelyea closed this Nov 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.