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

Add support for Paket guidance in display package. #4437

Closed
wants to merge 4 commits into
base: feature-redesign
from

Conversation

Projects
None yet
@isaacabraham
Contributor

isaacabraham commented Jul 20, 2017

No description provided.

@dnfclas

This comment has been minimized.

Show comment
Hide comment
@dnfclas

dnfclas Jul 20, 2017

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

dnfclas commented Jul 20, 2017

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

@joelverhagen

This comment has been minimized.

Show comment
Hide comment
@joelverhagen

joelverhagen Jul 20, 2017

Member

We want to keep the content on NuGet.org focused on the NuGet and dotnet CLI scenarios in the short term, given the client usage we are currently seeing in the wild. Hence, we won’t be merging this PR into the repo. Over time, we intend to make further changes to improve NuGet.org’s protocols with an explicit consideration towards promoting usage of other clients, and as a part of that effort, we will have guidance around this topic.

Member

joelverhagen commented Jul 20, 2017

We want to keep the content on NuGet.org focused on the NuGet and dotnet CLI scenarios in the short term, given the client usage we are currently seeing in the wild. Hence, we won’t be merging this PR into the repo. Over time, we intend to make further changes to improve NuGet.org’s protocols with an explicit consideration towards promoting usage of other clients, and as a part of that effort, we will have guidance around this topic.

@isaacabraham

This comment has been minimized.

Show comment
Hide comment
@isaacabraham

isaacabraham Jul 21, 2017

Contributor

@joelverhagen understood. However, this is a real pity as an extra tab that sits at the back of three does not risk confusing anyone, nor is this PR expensive to implement / deploy. As part of the NuGet project, and Microsoft's, new approach to open source and NIH, I had hoped that this would have been a good opportunity to demonstrate that.

Contributor

isaacabraham commented Jul 21, 2017

@joelverhagen understood. However, this is a real pity as an extra tab that sits at the back of three does not risk confusing anyone, nor is this PR expensive to implement / deploy. As part of the NuGet project, and Microsoft's, new approach to open source and NIH, I had hoped that this would have been a good opportunity to demonstrate that.

@BlythMeister

This comment has been minimized.

Show comment
Hide comment
@BlythMeister

BlythMeister Jul 21, 2017

The cla bot had it right, this is an important change to promote diversity of choice among the .net community with regard to package management.

Out of interest @joelverhagen how do you know client usage in the wild?

BlythMeister commented Jul 21, 2017

The cla bot had it right, this is an important change to promote diversity of choice among the .net community with regard to package management.

Out of interest @joelverhagen how do you know client usage in the wild?

@Mpdreamz

This comment has been minimized.

Show comment
Hide comment
@Mpdreamz

Mpdreamz Jul 21, 2017

I would like to voice my support for this change beyond a +1 icon. Hiding behind usage statistics is a bit of a self fulfilling prophesy and this seems like a super quick win.

If you guys have ideas around a grander vision to promote other clients, which it sounds like from your comment, that would be awesome too. Mind sharing your initial thoughts what improving nuget.org's protocols entails?

Mpdreamz commented Jul 21, 2017

I would like to voice my support for this change beyond a +1 icon. Hiding behind usage statistics is a bit of a self fulfilling prophesy and this seems like a super quick win.

If you guys have ideas around a grander vision to promote other clients, which it sounds like from your comment, that would be awesome too. Mind sharing your initial thoughts what improving nuget.org's protocols entails?

@Bomret

This comment has been minimized.

Show comment
Hide comment
@Bomret

Bomret Jul 21, 2017

I also want to chime in in support of this PR. Paket has helped me and colleagues in numerous situations where the official client took ages to resolve dependencies or failed upgrading packages solutionwide, for example. It is also around long enough, battle tested and very mature.
Also this extra tab does not hurt anyone and should be integratable very quickly as well as let you show that the OSS commitment Microsoft made is taken seriously. Or do you have any technical reasons not to do this?

Bomret commented Jul 21, 2017

I also want to chime in in support of this PR. Paket has helped me and colleagues in numerous situations where the official client took ages to resolve dependencies or failed upgrading packages solutionwide, for example. It is also around long enough, battle tested and very mature.
Also this extra tab does not hurt anyone and should be integratable very quickly as well as let you show that the OSS commitment Microsoft made is taken seriously. Or do you have any technical reasons not to do this?

@isaacabraham

This comment has been minimized.

Show comment
Hide comment
@isaacabraham

isaacabraham Jul 21, 2017

Contributor

@BlythMeister I assume from client requests. However this is actually a somewhat misleading figure since Paket has had machine-wide caching for a while now, which greatly reduces the number of actual download requests to nuget servers.

Contributor

isaacabraham commented Jul 21, 2017

@BlythMeister I assume from client requests. However this is actually a somewhat misleading figure since Paket has had machine-wide caching for a while now, which greatly reduces the number of actual download requests to nuget servers.

@robertpi

This comment has been minimized.

Show comment
Hide comment
@robertpi

robertpi Jul 21, 2017

Agree, as part of my professional life my team use paket as part of large .NET code base and paket has really helped us handle our external dependencies well. I do not understand why you wouldn't merge this very small PR.

robertpi commented Jul 21, 2017

Agree, as part of my professional life my team use paket as part of large .NET code base and paket has really helped us handle our external dependencies well. I do not understand why you wouldn't merge this very small PR.

@pmbanka

This comment has been minimized.

Show comment
Hide comment
@pmbanka

pmbanka Jul 24, 2017

We want to keep the content on NuGet.org focused on the NuGet and dotnet CLI scenarios in the short term, given the client usage we are currently seeing in the wild.

I can see some usage in the wild https://github.com/search?utf8=%E2%9C%93&q=paket.dependencies+in%3Apath&type=Code.

My perspective on the issue is that by not accepting this PR, you are making life of several thousand people just a tiny bit harder on daily basis (because they can't just copy paste a command, they need to type it manually).

I know I'm going to be slightly frustrated each time I will be going to nuget.org and copying package name/version number instead of quickly grabbing the whole command because of the site being "focused" 😞

pmbanka commented Jul 24, 2017

We want to keep the content on NuGet.org focused on the NuGet and dotnet CLI scenarios in the short term, given the client usage we are currently seeing in the wild.

I can see some usage in the wild https://github.com/search?utf8=%E2%9C%93&q=paket.dependencies+in%3Apath&type=Code.

My perspective on the issue is that by not accepting this PR, you are making life of several thousand people just a tiny bit harder on daily basis (because they can't just copy paste a command, they need to type it manually).

I know I'm going to be slightly frustrated each time I will be going to nuget.org and copying package name/version number instead of quickly grabbing the whole command because of the site being "focused" 😞

@isaacabraham

This comment has been minimized.

Show comment
Hide comment
@isaacabraham

isaacabraham Jul 25, 2017

Contributor

@joelverhagen I've thought about this over the weekend - perhaps you could elaborate a bit more on this one, as it's a bit confusing.

I can't personally see any negative impact, but that's just me. It's low risk, and very low impact - the only people it should affect are either people already using paket (in which case it's a positive impact), or people who are either unaware or interested in paket and might want to try it out. I suppose it's subjective whether that's considered that a positive or negative impact ;-)

Contributor

isaacabraham commented Jul 25, 2017

@joelverhagen I've thought about this over the weekend - perhaps you could elaborate a bit more on this one, as it's a bit confusing.

I can't personally see any negative impact, but that's just me. It's low risk, and very low impact - the only people it should affect are either people already using paket (in which case it's a positive impact), or people who are either unaware or interested in paket and might want to try it out. I suppose it's subjective whether that's considered that a positive or negative impact ;-)

@Bomret

This comment has been minimized.

Show comment
Hide comment
@Bomret

Bomret Jul 25, 2017

@isaacabraham you're not the only one who doesn't understand the reluctance to merge this ;) I can understand if there would be technical reasons. Everything else would just be political and of that "old Microsoft" I am very tired.

Bomret commented Jul 25, 2017

@isaacabraham you're not the only one who doesn't understand the reluctance to merge this ;) I can understand if there would be technical reasons. Everything else would just be political and of that "old Microsoft" I am very tired.

@isaacabraham

This comment has been minimized.

Show comment
Hide comment
@isaacabraham

isaacabraham Jul 25, 2017

Contributor

Wow. Just close the issue without answering the communities concerns / questions? Way to go, Microsoft.

Contributor

isaacabraham commented Jul 25, 2017

Wow. Just close the issue without answering the communities concerns / questions? Way to go, Microsoft.

@thinkbeforecoding

This comment has been minimized.

Show comment
Hide comment
@thinkbeforecoding

thinkbeforecoding Jul 25, 2017

We're using paket, and having insight for onboarding developers would help.
Not a big change IMHO but useful for the community and new users.

thinkbeforecoding commented Jul 25, 2017

We're using paket, and having insight for onboarding developers would help.
Not a big change IMHO but useful for the community and new users.

@AmadeusW

This comment has been minimized.

Show comment
Hide comment
@AmadeusW

AmadeusW Jul 25, 2017

by not accepting this PR, you are making life of several thousand people just a tiny bit harder on daily basis (because they can't just copy paste a command, they need to type it manually).

and that is exactly why developers move to Rider/AWS/Mac. One by one, in a seemingly insignificant trickle.

Over time, we intend to make further changes to improve NuGet.org’s protocols [...]

so after several talented developers leave Microsoft ecosystem for tools that work and tools they can improve, you will begin to consider what to do?

AmadeusW commented Jul 25, 2017

by not accepting this PR, you are making life of several thousand people just a tiny bit harder on daily basis (because they can't just copy paste a command, they need to type it manually).

and that is exactly why developers move to Rider/AWS/Mac. One by one, in a seemingly insignificant trickle.

Over time, we intend to make further changes to improve NuGet.org’s protocols [...]

so after several talented developers leave Microsoft ecosystem for tools that work and tools they can improve, you will begin to consider what to do?

@Thorium

This comment has been minimized.

Show comment
Hide comment
@Thorium

Thorium Jul 25, 2017

given the client usage we are currently seeing in the wild.

Just a note: NuGet.Core has 2 000 000 downloads in the Nuget. Paket is primarily downloaded from the GitHub, but still Paket has over 500 000 downloads in NuGet.

I assume Paket is using cache so the downloads are per machine. They can be found from
https://api.github.com/repos/fsprojects/paket/releases
There is only data for last few releases but from that we can see that Paket.exe has 31404 downloads in last 2 weeks. You have to add the NuGet-downloads to that. Doesn't sound a little insignificant open-source tool to me.

So can you describe your definiton of "in the wild" little more please?

Thorium commented Jul 25, 2017

given the client usage we are currently seeing in the wild.

Just a note: NuGet.Core has 2 000 000 downloads in the Nuget. Paket is primarily downloaded from the GitHub, but still Paket has over 500 000 downloads in NuGet.

I assume Paket is using cache so the downloads are per machine. They can be found from
https://api.github.com/repos/fsprojects/paket/releases
There is only data for last few releases but from that we can see that Paket.exe has 31404 downloads in last 2 weeks. You have to add the NuGet-downloads to that. Doesn't sound a little insignificant open-source tool to me.

So can you describe your definiton of "in the wild" little more please?

@danm-de

This comment has been minimized.

Show comment
Hide comment
@danm-de

danm-de Jul 25, 2017

Hmm..

Our company creates medical software (ISO 13485:2016) using Microsoft’s .Net technology. Unfortunately VS’s integrated package manager is not able to handle large solutions (just try to upgrade a single package having a lot of dependencies..).

paket helps us to create reliable and reproducible builds. VS package manager does not.

I would ask you to rethink your choice.

danm-de commented Jul 25, 2017

Hmm..

Our company creates medical software (ISO 13485:2016) using Microsoft’s .Net technology. Unfortunately VS’s integrated package manager is not able to handle large solutions (just try to upgrade a single package having a lot of dependencies..).

paket helps us to create reliable and reproducible builds. VS package manager does not.

I would ask you to rethink your choice.

@cdrnet

This comment has been minimized.

Show comment
Hide comment
@cdrnet

cdrnet Jul 25, 2017

I'd like to add that this pull request is also in the interest of large enterprise customers. We've entirely switched to Paket after assessing it to be the only NuGet client that meets our requirements (among others that it also works well with very large solutions and can provide guarantees like repeatable builds). Please reconsider your decision to close this pull request, as it would help us e.g. with the onboarding.

cdrnet commented Jul 25, 2017

I'd like to add that this pull request is also in the interest of large enterprise customers. We've entirely switched to Paket after assessing it to be the only NuGet client that meets our requirements (among others that it also works well with very large solutions and can provide guarantees like repeatable builds). Please reconsider your decision to close this pull request, as it would help us e.g. with the onboarding.

@baronfel

This comment has been minimized.

Show comment
Hide comment
@baronfel

baronfel Jul 25, 2017

I would submit as an example how Maven Central Repository displays package install instructions: https://mvnrepository.com/artifact/com.typesafe.akka/akka-actor_2.11/2.5.3.

image

You can see here that Maven, despite offering its own dependency management client, helps out everyone who consumes packages by showing various invocations for alternative package managers.

It's not hard to do, and it helps. Please reconsider this decision.

baronfel commented Jul 25, 2017

I would submit as an example how Maven Central Repository displays package install instructions: https://mvnrepository.com/artifact/com.typesafe.akka/akka-actor_2.11/2.5.3.

image

You can see here that Maven, despite offering its own dependency management client, helps out everyone who consumes packages by showing various invocations for alternative package managers.

It's not hard to do, and it helps. Please reconsider this decision.

@aspnetde

This comment has been minimized.

Show comment
Hide comment
@aspnetde

aspnetde Jul 25, 2017

Just be nice and do all of us a favor.

¯_(ツ)_/¯

aspnetde commented Jul 25, 2017

Just be nice and do all of us a favor.

¯_(ツ)_/¯

@creyke

This comment has been minimized.

Show comment
Hide comment
@creyke

creyke Jul 25, 2017

This will go viral and many people - myself included - will now be exposed to / have a play with Paket. Is that the intention?

creyke commented Jul 25, 2017

This will go viral and many people - myself included - will now be exposed to / have a play with Paket. Is that the intention?

@Bomret

This comment has been minimized.

Show comment
Hide comment
@Bomret

Bomret Jul 25, 2017

Holy smokes! You just closed PR, without any comments? Wow, just wow... 😞 So as you could not come up with technical reasons, because there seem to be none, it's obvious that this is a purely political decision. Back from the grave, "old Microsoft"?

Bomret commented Jul 25, 2017

Holy smokes! You just closed PR, without any comments? Wow, just wow... 😞 So as you could not come up with technical reasons, because there seem to be none, it's obvious that this is a purely political decision. Back from the grave, "old Microsoft"?

@ianbattersby

This comment has been minimized.

Show comment
Hide comment
@ianbattersby

ianbattersby Jul 25, 2017

Not feeling this should be merged is regretful, closing the issue without the necessary discussion and explanation is past disappointing. At least have the decency to reopen this for further discussion.

ianbattersby commented Jul 25, 2017

Not feeling this should be merged is regretful, closing the issue without the necessary discussion and explanation is past disappointing. At least have the decency to reopen this for further discussion.

@eriawan

This comment has been minimized.

Show comment
Hide comment
@eriawan

eriawan Jul 25, 2017

I support this PR and @isaacabraham for this matter.
Again, why is this issue closed? What are the real reasons?

I have used Paket in VS 2015 for 2 years until now, and VS 2017 for 6 months. It's far better than the default package management in VS 2015 Update 3 and even in VS 2017.2 (the current release of VS 2017). Paket can handle transitive dependency nicely and it also has higher performance when restoring nuget packages than the default nuget package management from Visual Studio 2015 and 2017.

IMHO, this issue-closing without further communication/clarification on the reason will just draw more support for Paket, while at the same time will give me hard time to give further good feedback for the default nuget tooling from Microsoft itself. 😞

Please reconsider to open this PR. I am sure it will not hurt anyone and it should be easy to support this.

cc @rrelyea, @emgarten, and the rest of the Nuget team...

eriawan commented Jul 25, 2017

I support this PR and @isaacabraham for this matter.
Again, why is this issue closed? What are the real reasons?

I have used Paket in VS 2015 for 2 years until now, and VS 2017 for 6 months. It's far better than the default package management in VS 2015 Update 3 and even in VS 2017.2 (the current release of VS 2017). Paket can handle transitive dependency nicely and it also has higher performance when restoring nuget packages than the default nuget package management from Visual Studio 2015 and 2017.

IMHO, this issue-closing without further communication/clarification on the reason will just draw more support for Paket, while at the same time will give me hard time to give further good feedback for the default nuget tooling from Microsoft itself. 😞

Please reconsider to open this PR. I am sure it will not hurt anyone and it should be easy to support this.

cc @rrelyea, @emgarten, and the rest of the Nuget team...

@ChrSteinert

This comment has been minimized.

Show comment
Hide comment
@ChrSteinert

ChrSteinert Jul 25, 2017

@joelverhagen - I guess there are good reasons why you simply closed this. There are most probably even good reasons, why there has been no further communication on why (or anything at all). I guess we could agree, that, while this your fair decision to make, it does not leave a nice feeling with all the supporters of this PR (not to think of @isaacabraham ...).
I guess it would be simply fair to step up and comment on these actions, state your intentions and we can all walk away peacefully. Do not let this get ugly - please?

ChrSteinert commented Jul 25, 2017

@joelverhagen - I guess there are good reasons why you simply closed this. There are most probably even good reasons, why there has been no further communication on why (or anything at all). I guess we could agree, that, while this your fair decision to make, it does not leave a nice feeling with all the supporters of this PR (not to think of @isaacabraham ...).
I guess it would be simply fair to step up and comment on these actions, state your intentions and we can all walk away peacefully. Do not let this get ugly - please?

@jschiefer

This comment has been minimized.

Show comment
Hide comment
@jschiefer

jschiefer Jul 25, 2017

Regardless of technical or political reasons, closing this PR without comment is just plain rude. This is not an acceptable way to interact with any OSS contributor.

jschiefer commented Jul 25, 2017

Regardless of technical or political reasons, closing this PR without comment is just plain rude. This is not an acceptable way to interact with any OSS contributor.

@isaacabraham

This comment has been minimized.

Show comment
Hide comment
@isaacabraham

isaacabraham Aug 4, 2017

Contributor

@unniravindranathan thanks for responding. Does this mean then that the issue is no longer one about the client meeting security requirements of the NuGet API etc., but merely about understanding how to make the change to the site so that it "fits in" properly?

As @ReedCopsey and others have alluded to - at the moment all sorts of reasons are being bandied about as to why to not accept the PR, but I'm still not entirely sure what the blocker is. We're all happy to work together to come up with a resolution that works for all parties - and a little bit of clarity at this point would greatly help.

Contributor

isaacabraham commented Aug 4, 2017

@unniravindranathan thanks for responding. Does this mean then that the issue is no longer one about the client meeting security requirements of the NuGet API etc., but merely about understanding how to make the change to the site so that it "fits in" properly?

As @ReedCopsey and others have alluded to - at the moment all sorts of reasons are being bandied about as to why to not accept the PR, but I'm still not entirely sure what the blocker is. We're all happy to work together to come up with a resolution that works for all parties - and a little bit of clarity at this point would greatly help.

@WilliamOckham

This comment has been minimized.

Show comment
Hide comment
@WilliamOckham

WilliamOckham Aug 4, 2017

After reading the official NuGet team response, I came to a fairly disturbing conclusion. Therefore, I want to make my assumptions clear. I believe the response was made in good faith and each of the points made in the response are relevant to the team's reasoning behind the decision to reject this PR. And, there is something missing from the response, because it is difficult for outsiders (including the submitter of the PR) to understand the connection between the points raised and the decision.

For me the question becomes, how does the discussion of future changes to the protocol, security concerns, and the need to constrain the universe relate to this PR? I admit, at this point, I'm engaging in something that is more hermeneutics than exegesis. We have to read between the lines here because the text is obscure (which frankly is not surprising, modern corporations tend to engender that sort of thing).

Let's breakdown the progression of the response, concentrating on the specific claims:

to further shore up NuGet’s security
we are looking at requiring submitters to sign packages and clients to respect signatures.
security changes for both the NuGet client and the server are in development.
we don’t have a solid proposal to take to the community quite yet.
we need[ed] to make [changes] to the various NuGet.org protocols to support these scenarios
we should keep the universe constrained [to just the official Microsoft clients]
For that reason, we thought it best to limit the number of clients we list on the website

If I understand this correctly, the reason that the PR was rejected was that the NuGet team is now in the process of breaking all the existing clients, but they can't tell us exactly how or when this will happen. Therefore the only NuGet clients that anyone can count on working are the official Microsoft clients. That sounds very much like the NuGet team envisions a possible future where no third-party clients are allowed to access the NuGet package repository. I hope I am wrong about this.

One way to prove me wrong is for the NuGet team to officially commit to not rolling out changes to the NuGet.org protocols until there is at least one third-party client implementation. That is a big ask, especially when the concern is security. On the other hand, the team should realize that a truly secure public protocol needs multiple implementations.

WilliamOckham commented Aug 4, 2017

After reading the official NuGet team response, I came to a fairly disturbing conclusion. Therefore, I want to make my assumptions clear. I believe the response was made in good faith and each of the points made in the response are relevant to the team's reasoning behind the decision to reject this PR. And, there is something missing from the response, because it is difficult for outsiders (including the submitter of the PR) to understand the connection between the points raised and the decision.

For me the question becomes, how does the discussion of future changes to the protocol, security concerns, and the need to constrain the universe relate to this PR? I admit, at this point, I'm engaging in something that is more hermeneutics than exegesis. We have to read between the lines here because the text is obscure (which frankly is not surprising, modern corporations tend to engender that sort of thing).

Let's breakdown the progression of the response, concentrating on the specific claims:

to further shore up NuGet’s security
we are looking at requiring submitters to sign packages and clients to respect signatures.
security changes for both the NuGet client and the server are in development.
we don’t have a solid proposal to take to the community quite yet.
we need[ed] to make [changes] to the various NuGet.org protocols to support these scenarios
we should keep the universe constrained [to just the official Microsoft clients]
For that reason, we thought it best to limit the number of clients we list on the website

If I understand this correctly, the reason that the PR was rejected was that the NuGet team is now in the process of breaking all the existing clients, but they can't tell us exactly how or when this will happen. Therefore the only NuGet clients that anyone can count on working are the official Microsoft clients. That sounds very much like the NuGet team envisions a possible future where no third-party clients are allowed to access the NuGet package repository. I hope I am wrong about this.

One way to prove me wrong is for the NuGet team to officially commit to not rolling out changes to the NuGet.org protocols until there is at least one third-party client implementation. That is a big ask, especially when the concern is security. On the other hand, the team should realize that a truly secure public protocol needs multiple implementations.

@PaulStovell

This comment has been minimized.

Show comment
Hide comment
@PaulStovell

PaulStovell Aug 5, 2017

Contributor

I'm confused too. Either future (possible) security changes will be breaking, in which case they will break all NuGet clients including all the people who have whatever NuGet came with their version of Visual Studio. I can't imagine Microsoft doing this.

Or, the changes will be optional - in which case older official NuGet clients will still work, as will Paket.

If you release a new, secure NuGet client but the instructions on the web page still say "Install-Package", people will still paste that into old NuGet clients and be "insecure". It would be no worse with Paket.

I can't see what practical difference such a future (possible) change would make. Either you break Paket and all the old official NuGet clients, or you don't. Older NuGet clients have shipped, that horse has bolted, and you can't break them.

The deeper issue seems to be more of a desire to maintain control of the ecosystem - that ideally every NuGet user would use an official client and therefore you maintain control for the future. In which case you should probably just make it clear: we don't want people to use alternative clients, and we aren't ashamed to admit that.

Contributor

PaulStovell commented Aug 5, 2017

I'm confused too. Either future (possible) security changes will be breaking, in which case they will break all NuGet clients including all the people who have whatever NuGet came with their version of Visual Studio. I can't imagine Microsoft doing this.

Or, the changes will be optional - in which case older official NuGet clients will still work, as will Paket.

If you release a new, secure NuGet client but the instructions on the web page still say "Install-Package", people will still paste that into old NuGet clients and be "insecure". It would be no worse with Paket.

I can't see what practical difference such a future (possible) change would make. Either you break Paket and all the old official NuGet clients, or you don't. Older NuGet clients have shipped, that horse has bolted, and you can't break them.

The deeper issue seems to be more of a desire to maintain control of the ecosystem - that ideally every NuGet user would use an official client and therefore you maintain control for the future. In which case you should probably just make it clear: we don't want people to use alternative clients, and we aren't ashamed to admit that.

@SeanKilleen

This comment has been minimized.

Show comment
Hide comment
@SeanKilleen

SeanKilleen Aug 5, 2017

Okay, okay, I couldn't resist...had an urge to develop something small and this seemed like a good opportunity for a Chrome extension 😆

Figured a little levity doesn't hurt here.

SeanKilleen commented Aug 5, 2017

Okay, okay, I couldn't resist...had an urge to develop something small and this seemed like a good opportunity for a Chrome extension 😆

Figured a little levity doesn't hurt here.

@FransBouma

This comment has been minimized.

Show comment
Hide comment
@FransBouma

FransBouma Aug 5, 2017

@WilliamOckham well said.

(Disclaimer: I'll likely hurt some people's feelings in the following text, but I don't really care) I think (so this is speculation, but to me it clearly looks like this) there's some internal struggle within the team what to do with 'the community'. Since forever the NuGet team has been the prototype of an ivory tower occupying dev team where the rest of the world could see and change the code but there was little two-way interaction. Nothing wrong with that, every team has to work the way they want and if that works for them, great. It has side effects though, and these consequences have to be taken into account. I think this PR and especially its aftermath show the side effects of not completely working with the community/outside world are not properly handled within the NuGet team. In short: they were ignored for long, but that has backfired.

The reply (and the follow up #4510 issue, really.. some government officials produce less overhead for such a small thing, NuGet team!) was/is appreciated but it simply shows more about the internal struggle I think is happening and doesn't fix anything.

To me the NuGet team has to choose what to do, going forward: (Mind you, either one of them is OK to me, like I said: whatever the situation, there are consequences to them, so less engagement with the community has the result of the community feeling left out, and otoh more engagement with the community will result in giving up more freedom to do whatever the nuget team wants... it's a balance)

  • Decide they're the source of truth all things NuGet (client, server, protocol) and the outside world is a follower, who can give feedback which is occasionally picked up but only if it serves this status quo. They're primarily there to serve the interests of the platform holder, Microsoft.
  • Decide they're there solely to serve the community's interests and therefore NuGet first and foremost is designed and operated with that in mind: what the community wants is key and drives NuGet going forward. This might not serve the interests of the platform holder, Microsoft.

Now these two are extremes, there are many forms in between, I just picked these two to prove my point and as an example. But whatever the Nuget team decides to do, it benefits all involved that they make a decision about it, so we all know what we can expect.

FransBouma commented Aug 5, 2017

@WilliamOckham well said.

(Disclaimer: I'll likely hurt some people's feelings in the following text, but I don't really care) I think (so this is speculation, but to me it clearly looks like this) there's some internal struggle within the team what to do with 'the community'. Since forever the NuGet team has been the prototype of an ivory tower occupying dev team where the rest of the world could see and change the code but there was little two-way interaction. Nothing wrong with that, every team has to work the way they want and if that works for them, great. It has side effects though, and these consequences have to be taken into account. I think this PR and especially its aftermath show the side effects of not completely working with the community/outside world are not properly handled within the NuGet team. In short: they were ignored for long, but that has backfired.

The reply (and the follow up #4510 issue, really.. some government officials produce less overhead for such a small thing, NuGet team!) was/is appreciated but it simply shows more about the internal struggle I think is happening and doesn't fix anything.

To me the NuGet team has to choose what to do, going forward: (Mind you, either one of them is OK to me, like I said: whatever the situation, there are consequences to them, so less engagement with the community has the result of the community feeling left out, and otoh more engagement with the community will result in giving up more freedom to do whatever the nuget team wants... it's a balance)

  • Decide they're the source of truth all things NuGet (client, server, protocol) and the outside world is a follower, who can give feedback which is occasionally picked up but only if it serves this status quo. They're primarily there to serve the interests of the platform holder, Microsoft.
  • Decide they're there solely to serve the community's interests and therefore NuGet first and foremost is designed and operated with that in mind: what the community wants is key and drives NuGet going forward. This might not serve the interests of the platform holder, Microsoft.

Now these two are extremes, there are many forms in between, I just picked these two to prove my point and as an example. But whatever the Nuget team decides to do, it benefits all involved that they make a decision about it, so we all know what we can expect.

@Bomret

This comment has been minimized.

Show comment
Hide comment
@Bomret

Bomret Aug 5, 2017

I don't really get it either. Let me just try to think out loud and anyone correct me if I'm wrong:

  • there are official nuget.org api's (v2 and v3, right?) that Paket supports and most other unofficial clients too, to some extend.
  • you (the nuget team) seem to want/have to make breaking changes.

Where exactly is the problem again? You release your breaking changes as a new API version that is documented so everyone can just use it. You also deprecate the older API versions that you want to get rid of and give a date when they will be switched off. In my experience supporting the previous and current API versions are good practice. So you only ever have to support two versions.
But as I said, the client in question for this PR (Paket) already supports the current API versions. So there is absolutely no blocker imho that prevents you from merging this PR.

Bomret commented Aug 5, 2017

I don't really get it either. Let me just try to think out loud and anyone correct me if I'm wrong:

  • there are official nuget.org api's (v2 and v3, right?) that Paket supports and most other unofficial clients too, to some extend.
  • you (the nuget team) seem to want/have to make breaking changes.

Where exactly is the problem again? You release your breaking changes as a new API version that is documented so everyone can just use it. You also deprecate the older API versions that you want to get rid of and give a date when they will be switched off. In my experience supporting the previous and current API versions are good practice. So you only ever have to support two versions.
But as I said, the client in question for this PR (Paket) already supports the current API versions. So there is absolutely no blocker imho that prevents you from merging this PR.

@gep13 gep13 referenced this pull request Aug 5, 2017

Closed

Add other CLI tools? #3

@Thorium

This comment has been minimized.

Show comment
Hide comment
@Thorium

Thorium Aug 6, 2017

But I do want to make sure that we're being fair to all NuGet clients

All? Do you mean both NuGet and Paket? Let us be unfare to Paket so that if there ever will be a third one, its instructions will also be missing.

Thorium commented Aug 6, 2017

But I do want to make sure that we're being fair to all NuGet clients

All? Do you mean both NuGet and Paket? Let us be unfare to Paket so that if there ever will be a third one, its instructions will also be missing.

@nexussays

This comment has been minimized.

Show comment
Hide comment
@nexussays

nexussays Aug 7, 2017

I'll move any further discussion to #4510 as requested, but since I jumped in with a sky is falling comment RE the behavior displayed at the outset of this issue, I just want to say thank you to @unniravindranathan for jumping into the fray in an open an honest way. This is what should have happened from the outset.

For the record, while I don't use Paket on any personal or professional projects, I think the reasons offered for rejecting this PR are wholly insufficient. As a NuGet user, adding Paket install instructions to the nuget.org homepage has zero negative impact on me and huge positive impact on the .Net ecosystem as a whole.

Looking forward to a bright future where issues like this one are accepted with a "Great idea! Thanks for the PR!"

nexussays commented Aug 7, 2017

I'll move any further discussion to #4510 as requested, but since I jumped in with a sky is falling comment RE the behavior displayed at the outset of this issue, I just want to say thank you to @unniravindranathan for jumping into the fray in an open an honest way. This is what should have happened from the outset.

For the record, while I don't use Paket on any personal or professional projects, I think the reasons offered for rejecting this PR are wholly insufficient. As a NuGet user, adding Paket install instructions to the nuget.org homepage has zero negative impact on me and huge positive impact on the .Net ecosystem as a whole.

Looking forward to a bright future where issues like this one are accepted with a "Great idea! Thanks for the PR!"

@xperiandri

This comment has been minimized.

Show comment
Hide comment
@xperiandri

xperiandri Aug 9, 2017

It is crazy.

xperiandri commented Aug 9, 2017

It is crazy.

@ReedCopsey

This comment has been minimized.

Show comment
Hide comment
@ReedCopsey

ReedCopsey Aug 15, 2017

@unniravindranathan First off, congrats on getting the new site + all of the changes for .NET Core 2 out the door.

Now that you've shipped, would you consider reopening this issue (as I mentioned previously ), and keeping the discussion moving on #4510 ?

ReedCopsey commented Aug 15, 2017

@unniravindranathan First off, congrats on getting the new site + all of the changes for .NET Core 2 out the door.

Now that you've shipped, would you consider reopening this issue (as I mentioned previously ), and keeping the discussion moving on #4510 ?

@JohanLarsson

This comment has been minimized.

Show comment
Hide comment
@JohanLarsson

JohanLarsson Aug 16, 2017

Please reopen this.

JohanLarsson commented Aug 16, 2017

Please reopen this.

@haf haf referenced this pull request Aug 20, 2017

Open

Homebrew formula #533

@anangaur

This comment has been minimized.

Show comment
Hide comment
@anangaur

anangaur Sep 8, 2017

Member

Update: The criteria was defined as part of #4510 and the required changes to enable third-party tabs is done now. Please refer to the associated PR on the issue: #4589 to understand the changes required to enable third-party clients on package details page.

@isaacabraham, Can you submit a new PR based on the new changes? If you would like to submit the changes as part of this PR, do let me know so that I can reopen it.

Member

anangaur commented Sep 8, 2017

Update: The criteria was defined as part of #4510 and the required changes to enable third-party tabs is done now. Please refer to the associated PR on the issue: #4589 to understand the changes required to enable third-party clients on package details page.

@isaacabraham, Can you submit a new PR based on the new changes? If you would like to submit the changes as part of this PR, do let me know so that I can reopen it.

@isaacabraham

This comment has been minimized.

Show comment
Hide comment
@isaacabraham

isaacabraham Sep 8, 2017

Contributor

@anangaur please do re-open this - then I can modify it and it's all kept in one place. Thanks!

Contributor

isaacabraham commented Sep 8, 2017

@anangaur please do re-open this - then I can modify it and it's all kept in one place. Thanks!

@anangaur anangaur reopened this Sep 9, 2017

@dnfclas

This comment has been minimized.

Show comment
Hide comment
@dnfclas

dnfclas Sep 9, 2017

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

dnfclas commented Sep 9, 2017

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

isaacabraham and others added some commits Sep 9, 2017

Merge remote-tracking branch 'origin/feature-redesign' into feature-r…
…edesign

# Conflicts:
#	src/NuGetGallery/Views/Packages/DisplayPackage.cshtml
Added tab for Paket
Signed-off-by: Isaac Abraham <isaac.abraham@gmail.com>
@isaacabraham

This comment has been minimized.

Show comment
Hide comment
@isaacabraham

isaacabraham Sep 9, 2017

Contributor

@anangaur I've updated the PR branch so that it's up to date with the latest feature-redesign and have then applied the patch from @loic-sharma (thanks for this!). So I think that this is good to go, but please check - if it needs more, just let me know - I've actually never applied a patch file before, but I think I've done it correctly.

Contributor

isaacabraham commented Sep 9, 2017

@anangaur I've updated the PR branch so that it's up to date with the latest feature-redesign and have then applied the patch from @loic-sharma (thanks for this!). So I think that this is good to go, but please check - if it needs more, just let me know - I've actually never applied a patch file before, but I think I've done it correctly.

@loic-sharma

This comment has been minimized.

Show comment
Hide comment
@loic-sharma

loic-sharma Sep 9, 2017

Member

The feature-redesign branch is no longer active and is quite behind now - could you target the dev branch instead? Thanks for updating your pull request! :)

Member

loic-sharma commented Sep 9, 2017

The feature-redesign branch is no longer active and is quite behind now - could you target the dev branch instead? Thanks for updating your pull request! :)

@isaacabraham

This comment has been minimized.

Show comment
Hide comment
@isaacabraham

isaacabraham Sep 9, 2017

Contributor

@loic-sharma in which case I should probably make a brand new PR then that targets that branch instead?

Contributor

isaacabraham commented Sep 9, 2017

@loic-sharma in which case I should probably make a brand new PR then that targets that branch instead?

@isaacabraham

This comment has been minimized.

Show comment
Hide comment
@isaacabraham

isaacabraham Sep 9, 2017

Contributor

I've created #4638 now based off of dev - please feel free to close this one (again ;-).

Contributor

isaacabraham commented Sep 9, 2017

I've created #4638 now based off of dev - please feel free to close this one (again ;-).

@anangaur

This comment has been minimized.

Show comment
Hide comment
@anangaur

anangaur Sep 11, 2017

Member

@isaacabraham I will rather have you do the honors this time ;)
Please feel free to close this one since the other PR:#4638 is out.

Member

anangaur commented Sep 11, 2017

@isaacabraham I will rather have you do the honors this time ;)
Please feel free to close this one since the other PR:#4638 is out.

@hickford

This comment has been minimized.

Show comment
Hide comment
@hickford

hickford Nov 20, 2017

Contributor

If it interests anyone, looking at the stats for the most popular packages, you can see Paket now accounts for between 1% and 3% of downloads:

  1. 1% of Newtonsoft.Json downloads
  2. 3% of NUnit downloads

As you'd expect, Paket is most popular in the F# community:

  1. 25% of FSharp.Core downloads
  2. 48% of FSharp.Charting downloads

Thanks NuGet for publishing these. It'd be neat if https://www.nuget.org/stats showed overall statistics

Contributor

hickford commented Nov 20, 2017

If it interests anyone, looking at the stats for the most popular packages, you can see Paket now accounts for between 1% and 3% of downloads:

  1. 1% of Newtonsoft.Json downloads
  2. 3% of NUnit downloads

As you'd expect, Paket is most popular in the F# community:

  1. 25% of FSharp.Core downloads
  2. 48% of FSharp.Charting downloads

Thanks NuGet for publishing these. It'd be neat if https://www.nuget.org/stats showed overall statistics

@tebeco

This comment has been minimized.

Show comment
Hide comment
@tebeco

tebeco Nov 20, 2017

i totally agree this is a real scandal that paket use the cache so well !!!

tebeco commented Nov 20, 2017

i totally agree this is a real scandal that paket use the cache so well !!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment