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

Support MyGet and pre-release packages for all nuget kind of feeds #235

Merged
merged 2 commits into from
Aug 28, 2014

Conversation

Alxandr
Copy link
Contributor

@Alxandr Alxandr commented Aug 8, 2014

Added support for myget, and getting version/download information for packages that only have pre-release versions.

@Alxandr
Copy link
Contributor Author

Alxandr commented Aug 8, 2014

Refer to #233

@Alxandr
Copy link
Contributor Author

Alxandr commented Aug 11, 2014

I notice the test failing, but I've never been able to get the tests running locally, so I'm not sure how to fix/debug this. I get the same test-failures with or without my changes.

@espadrine
Copy link
Member

Thanks for contributing! (I still need a little more time to review this, sorry for the delay…)

The tests should pass with npm test. The Travis fails are recent; I'll look into them within a few days.

Out of curiosity, what is the relationship between NuGet and MyGet? Are they competitors?

@Alxandr
Copy link
Contributor Author

Alxandr commented Aug 12, 2014

No. NuGet is 2 things. First it's the program/protocol used to install nuget packages. Than there's the "central repository" with the same name, known as nuget.org. However, it's quite doable to set up your own repositories. So companies can have their own repositories for instance to share internal stuff behind a firewall.

Just as an example, both teamcity and appveyor comes with built in nuget feed capabilities.

MyGet is nuget feeds as a service. It allows you to create your own feeds that you can publish packages to, that does not show up as nuget central, meaning if people want your packages, they have to add your feed. It tend to be used for stuff like nightlies and feeds where you just push straight from CI (never been quality tested), and you can push "propper" releases, or milestones to nuget central for "general availability".

@Alxandr
Copy link
Contributor Author

Alxandr commented Aug 12, 2014

Also, as said. npm test never worked on my environment. But the failures are consistent with and without my changes. It's not able to connect to some server that's probably being setupt. I can get you a failure log if you'd like.

@Alxandr
Copy link
Contributor Author

Alxandr commented Aug 19, 2014

Any news on this? Anything that needs to be fixed? Or things that need be explained?

@espadrine espadrine merged commit 9b38c60 into badges:master Aug 28, 2014
@espadrine
Copy link
Member

First off, I am terribly sorry that it took as long as it did. First I was busy, then I was quite ill, but it is no justification.

Secondly, thanks a lot! This was a very good pull request, and your answers were stellar and helped me a lot.

Finally, the code is live on http://shields.io.

@espadrine
Copy link
Member

As an aside, I believe that the reason npm test failed to work is that you had a server running. The test server actively tries to connect to port 1111 specifically.

@Alxandr
Copy link
Contributor Author

Alxandr commented Aug 28, 2014

Thank you :)

They are put to good use here: https://github.com/YoloDev/FSharpSupport :)

Also, I was thinking, (for a later time when somebody have time to figure out how it would work exactly), it would be nice to be able to specify if you want the AbsoluteLatestVersion (ie. including pre-releases), or just the latest released version. As of now it defaults to latest released and falls back to the latest pre-release.

@espadrine
Copy link
Member

I agree. If you want to take a stab at implementing this, it is very dearly welcome!

I believe Gem downloads offer this kind of separation. Some background discussion on that was here: #212.

@Alxandr
Copy link
Contributor Author

Alxandr commented Sep 3, 2014

If you look at my code it'd be a quick (prolly 10-30 min) fix to add. However I'm unsure how the URI scheme should look. nuget/v/package.svg?style=flat&pre?

@espadrine
Copy link
Member

I suppose the URL could be nuget/vpre/package.svg, or maybe nuget/vα/package.svg, to specify that we want the alpha version if it exists. If you think unicode is too dangerous, maybe nuget/va/package.svg.

What are the synonyms there? Pre-release, trunk, head, alpha, nightly, dev, … I kind of like "a" for alpha, but "dev" is good as well.

@Alxandr
Copy link
Contributor Author

Alxandr commented Sep 4, 2014

I think the current functionality should stay though, so that if you do just v, you get the latest release version if one exists, otherwise you get pre-release, agreed?

@espadrine
Copy link
Member

Entirely!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants