Add support for Paket guidance in display package.

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

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.

@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 step to demonstrate that.

The cla bot had it right, this is an important change to promote diversity among package management.

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?

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?

@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.

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.

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=✓&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" 😞

@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 ;-)

@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.

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

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.

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?

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 30 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 state your definiton of "in the wild" little more please?

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.

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 (primarily that it also works well with very large solutions). Please reconsider your decision to close this pull request.

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.

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.

Just be nice and do all of us a favor.
¯_(ツ)_/¯

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

Holy smokes! You just closed PR, without any comments? Wow, just wow... 😞

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.

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...

@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.

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.

As a consultant I've introduced Paket as dependency management tool in every company I've been working with for last 2 years. No one ever complained about it, people could see clear advantages such as resolution strategy, lock files that creates reproducible builds, making clear separation of direct and indirect dependencies, great xplat support etc.
But technical differences are not really important here. What's the most important part is here is the fact that you are directly hurting ecosystem, making life of thousands of people more difficult for no reason other than an ego. Such behavior is actively sabotaging work of many great people that promotes "new MSFT", Open Source Software, and Community based approach to managing ecosystem. Adding Paket tab has no drawbacks, no cost, it's added value and it will promote nuget.org
Rejecting PRs is fine - many of people commenting on this thread are contributors and maintainers, we know the drill. But rejecting PR that doesn't introduce any maintenance cost, is low risk, and targets something that's important for at least part of the community (what is shown by Paket download stats, thousands of OSS projects on GitHub using it, and clear support in this thread) without any communication is just plain wrong.

I use F# scripts for empirical research. Paket is much easier for this scenario.
This pull request would make my life just a little bit easier. Please consider.

Please reconsider this decision. We all benefit from a vibrant ecosystem with good quality choices which are easy to find and use - isn't that what Nuget is about anyway?

Ian Cooper discusses this problem in his talk on "Creating A .NET Renaissance". As he says there, "it doesn't help when Microsoft crushes innovation".
Please, please, at least comment on this PR properly -- how can you expect an active .NET ecosystem to exist when you behave like this?

Paket is a really nice tool from which nuget.org can benefit.
Please reconsider this decision.

Without Paket, NuGet is  barely usable. Please, explain your decision.

Not to downplay any of the comments praising Paket, but I don't understand the idea that this was closed without explanation.
What could @joelverhagen possibly add beyond repeating everything he said in his original comment?

Managing the official nuget server and gallery for .NET ecosystem mean you shouldnt cripple it, just because.
Change is harmless, was done by community and just give more more docs for users.
The guidance will be for who? atm there are just two package managers (invoke same nuget client with different sintax doesnt really count..) .
Please just collaborate instead of fight, i was expecting more from new MS and .NET.
maybe the .NET Foundation can help with this /cc @jongalloway

Difficult to see the downside in supporting this pr I use both the packet and nuget clients having guidance for both would be a great help. Just closing this pr is does not support the open source message that is presented by ms. And which I believe has the potential to aid the .net Renaissance - actions like this while in the scope of the whole ecosystem are small perpetuate the old impression of ms and turn people off the platform

@tldrlol several questions were posted in response to that, which suggests that perhaps the answer wasn't as clear as it could've been.

As an example, npm is an open register that follows standards and makes it easy for other clients to manage their packages. Their own client had problems (like the absence of a lock file), then yarn came out to solve them and had a great acceptance by the community. Driven by this, now npm client has adopted several of yarn features and as a result, the ecosystem is stronger and users are much happier (faster downloads, reproducible builds).

BTW, npm only lists install instructions for its own client in their site, but at the same time it makes the project README more prominent and there authors can write whatever they want.

A lock file (committed to the repo), like the one Paket has, is absolutely crucial for OSS maintainers as it makes it possible for other users to have reproducible builds when cloning a repo. Without it, many potential contributors give up when they cannot build a fork because of some obscure dependency problem. I myself have suffered this when trying to contribute to Visual F# repository because of this.
Finally, some packages hosted on nuget.org do need Paket. Fable related packages for example (more than 45,000 downloads) need features that Nuget client does not offer: like listing packages in proper dependency order to reconstruct the hierarchy tree, or tying the version of a CLI tool to a library.

I can't understand the reasoning behind not merging this PR. Surely making it easier to integrate with Nuget from a variety of clients can only benefit nuget.org and the whole .Net ecosystem. Having come from a JVM language background originally before moving to .Net, I'm really surprised at this because I am so used to  mvnrepository.com where it's really easy to see different ways to integrate packages with a variety of clients from maven to leinigen. I would love to see more developers from a JVM background give .Net a try and I think tooling and an open and inclusive ecosystem would be a great attraction for them.

@tldrlol When he wrote:

"We want to keep the content on NuGet.org focused on the NuGet and dotnet CLI scenarios..."

it came across to many people as:

"we say that we want to support the .NET FOSS community, but in practice, we don't want to support non-MS tooling because it's not under our control"

We all sincerely hope that he doesn't mean that, and it's a misunderstanding. Having a discussion about what MS plans are in this regard would be very helpful, rather than just closing without further comment.

@joelverhagen unbelievably rude and outrageous to close and not even have the decency to reply to any of the subsequent responses. Undermines all the effort put into paket and all OSS. If nuget client wasn't so poor we wouldn't need OSS alternatives like Paket, what's the point of having this as OSS if you are not accepting PR to help promote the .net platform, this is one of the ever increasing reasons .net is dying and cannot compete with actual OSS.

It's most 👍ed issue/PR in this repo history - https://github.com/NuGet/NuGetGallery/issues?q=sort%3Areactions-%2B1-desc

Can't really understand why not merging something which will benefit to all people.
We don't force people to use paket by simply adding the instruction... Neither leave nuget etc.
Can you explain your decision please :) ?

@swlaschin Had I stopped reading at that point, I might have gotten the same impression.

Add me to the list of people who believe Microsoft should have a second look at this PR.  Paket is pretty great and there is no downside to giving it greater visibility.

My 2cent: Even if I don't use Paket the additional tab will not hurt anyone and (as you can clearly see) Paket has a loud community and it deserves a bit more attention.

@tldrlol The remainder of his comment sounds like vague promises to me. "We can't do anything until we get guidance" gives the impression that there is still a culture of control and worry about non-MS tools. I'm not sure why they need guidance to accept a PR which has no downsides. Does it need to be reviewed by a lawyer? By a senior manager? If so, why? And if not, why not just accept the PR, given that it is clearly popular?  It would be nice to have some openness so that we can understand the reasoning that went into this decision.

Yes please! Give us at least some transparency on why this PR should not be merged.

Small reminder that Paket is actually used by MSFT in production in one of the Azure products as user facing dependency manager, used internally to build some Azure products, used by in couple of OSS projects and mentioned in official documentation, for example, couple of times in Getting started with F# in VSCode tutorial.
So I don't really understand why any special guidance around the topic would be needed

I'm all in for this PR to be merged. As a contributor and heavy consumer of Paket I think it could make MSFT and Paket community more positive towards each other

I am all for having this PR merged. Paket is an integral part of our Azure functions application workflow.

Just don't see why Paket and Nuget can't work together. Paket solves issues that would be  a breaking change in nuget, and makes it better in the process.

please reconsider this and reopen the PR

It's never late to get off the tree 🙂

@isaacabraham's comment has more up-votes than this NuGet repository has contributors. So it seems that there are still developers in the .NET community, even if they are not interested in contributing NuGet.
Wonder why is that?

I remember when we in the .NET community made fun of Java people coz things seemed stuck in time. @baronfel 's comment shows they're now more accepting of things than we are.
I've introduced packet at a few clients, and every time they've appreciated it. I can't fathom why an additive PR which doesn't take anything away from NuGet itself, but rather promotes an excellent community built .NET tool should not be accepted.

I hope I'm not trolling anyone, but the longer this PR not responded nor clarified, the more community developers will be in doubt or even have disappointment on this silence treatment.
Contrary to the other most official Microsoft's blog posts and corporate announcements that said MS is open, this harsh PR closing is proving otherwise. I am aware that Microsoft has full rights to close this PR, but simply closing this PR without impeccable reason or meaningful explanation for me is the same as defensive and/or closed stance. Once you are open in GitHub or any other open source repo such as BitBucket, put it simply, this means it is closed stance instead of open stance to community.
Although I could be biased because I have used Paket for most of my projects, but this drama really state the fact that MS is somehow showing disrespect to other nuget client or tooling community.

So I don't really understand why any special guidance around the topic would be needed
Yes, me too. If there's special guidance around the topic is available, why is there no evidence of this?

Also going back to the mostly asked question on this PR, why is so hard to give official and honest explanation or simply merge this PR?

I'm using Paket for all my work. Be it personal or professional. Nothing much against nuget or professionals using nuget. But I have a choice and I made it.
Because new MSFT is not only allowing but also promoting it. At least on paper.
There can be rejected PR, also different goals but an explanation would be way better than shutting a door on open source project.
I guess we are way pass old MSFT and can expect  much more.
Please reopen and consider this PR. Or atleast provide a good technical, legal or even political reason to close it.

Disclosure: MSFT employee, unrelated department, not at all involved in decision.  Also I used Paket for three years prior to my job here.
I can understand.  Last few years, opening up of MSFT, there's been so much "you used to have to do it this way, but now you can do this thing or this thing or even this thing", and customers ended up doing all mix of things with no idea what was the right thing.  So clients started doing half of each of those things, each in their own way, that supporting every conceivable permutation (plenty of them bad) has become a conundrum.
So I think there's lately a bit of a focus toward "let's quit providing options, and provide recommendations instead".  This PR is just adding an option.
I think it's a good option to add, but until it gets vetted through the documentation team, etc, it's just another option that too many corps will invariably use incorrectly and end up making MSFT look unfocused (in the eyes of those who matter $).
My guess is this is the reason for closing.  Could be completely wrong.  The lack of communication with regards to that, while disappointing, I'll not critique; we all work under our own time crunches.

What is up with Microsoft not getting how to talk to people. This is the same weird silence we got when C# stuff was going to be moved to a mailing list. Please hire someone to actually manage this as their job because it's pretty obvious that nobody is being paid to do this.

So I think there's lately a bit of a focus toward "let's quit providing options, and provide recommendations instead". This PR is just adding an option.

This is really interesting point, not only in context of this PR. I'd imagine that "opening of MSFT", and embracing OSS approach is about empowering Community to provide those options. Instead we learn that "new, open MSFT" is about MSFT telling customers what should they use. Thanks for clarification! :)

@Krzysztof-Cieslak I'm four months in MSFT and totally with you (the only reason I stumbled across this is that I follow you on twitter), so the cynicism is ... weird.
But I have to say, that once MSFT "owns" something by taking on a pull request like this, then suddenly since it's "officially supported" then support gets called by all variety of companies that are having trouble with this new thing, and somebody (me, been there, deserve better) is woken up in the middle of the night to help fix the customer's problems, and nobody on call knows anything about this thing called "paket", etc....
So it's not like MSFT can just take any old thing out of the blue and say it's supported.  To inject something, at the core of the development environment like this, even as a third-tab option, well, at least the on-call engineer's sleep needs to be taken into account.

(the only reason I stumbled across this is that I follow you on twitter), so the cynicism is ... weird.

Hah, if you follow me on Twitter then you know that cynicism is .... commonly used tool by me ;-) No bad feelings here. :-)

But I have to say, that once MSFT "owns" something by taking on a pull request like this, then suddenly since it's "officially supported" then support gets called by all variety of companies that are having trouble with this new thing, and somebody (me, been there, deserve better) is woken up in the middle of the night to help fix the customer's problems, and nobody on call knows anything about this thing called "paket", etc....

This is really good argument, and I bet many people commenting in this thread would understand and accept such explanation. But:

it should be "official" (i.e made by member of Team),
it should be given before closing the issue

Also, it would be cool to know what's the difference between including it here, and all other places where Paket is already included, used, and mentioned in documentation as I've mentioned in earlier comment

But I have to say, that once MSFT "owns" something by taking on a pull request like this, then suddenly since it's "officially supported" then support gets called by all variety of companies that are having trouble with this new thing, and somebody (me, been there, deserve better) is woken up in the middle of the night to help fix the customer's problems, and nobody on call knows anything about this thing called "paket", etc

I think you are pushing a false alternative. Just because MSFT is supportive of an OSS tool does not mean they need to support it. The situation is more nuanced. Consider pre-release software, it comes out under the MSFT banner but is not supported.

@jbeeko Big Corps that are MSFT clients don't care much about nuance.  Supportive of still gets on-calls woken up in the middle of the night.

@daxfoh

Big Corps that are MSFT clients don't care much about nuance. Supportive of still gets on-calls woken up in the middle of the night.

Well that is in the realm of messaging, support contracts and, fees. And it could well be that as long as that story is not ready MSFT can't appear to bless an OSS tool too directly. But if MSFT wants to mix it up in the OSS space the guys who get paid the big bucks need to figure it out. Soon would be nice, and a direct explanation of the issue would build trust.

@jbeeko Perhaps.  Permutations of options are permutations of support costs.  Someone else did that math.  I wasn't involved in the decision to close this issue, just providing what wee bit of insight I could from where I am.

and nobody on call knows anything about this thing called "paket"

Then this is a part of the problem (and MS attitude) taken into account how popular Paket is among developers. Can you imagine the same being said about Newtonsoft.Json? Of course not. But even though JSON.NET has far more downloads than Paket, its repo has only 59 contributors while Paket has 199. So there is probably a better chance to resolve Paket an issue or question quicker than an issue with JSON serializer.
I see you point with this argument - yes, promoting Paket requires business commitments. It's just that when an OSS tool reaches certain level of popularity and usage, including usage by Microsoft employees, there comes a time when Microsoft should offer such commitment, especially since the time to get a response on a Paket issue is always short (and newly discovered bugs often get patched the same day).

@object well for each third-party thing, you also have to consider, "what if the first step of this thing is 'take all our code and upload to our competitors'".  This is entirely possible, so adopting third-party libraries that, sure, are super popular in the freelancing world where that doesn't matter much, is not a light undertaking in the corporate world.

@daxfohl Sure it is not. It's about weighing options and costs. Microsoft has become much better in embracing OSS, and this was a smart, practical move - otherwise they would have lost a large part of its development community. So it's just to continue moving in a right direction, and response to this PR so far doesn't look like a step in that direction.

well for each third-party thing, you also have to consider, "what if the first step of this thing is 'take all our code and upload to our competitors'".

Again, I'd assume that's not a problem in this case since Paket got "cleared" enough to be used on the runtime of Azure Notebooks which are not some random MSR project, but general available Azure product.
Also, same point can be done about every third-party dependency that any MS product is using. Are those big corporations worried about Json.Net dependency in ASP.Net Core ? Who fixes bugs in Json.Net, who responds to those support calls in Json.Net ?

Also, please bear in mind that we are all time speculating about possible reasons since there is no response from NuGet team

@Krzysztof-Cieslak

Also, please bear in mind that we are all time speculating about possible reasons since there is no response from NuGet team

So true. The longer is no response, the more FUD (not just speculations) we have.
There's also old saying: "no news is bad news" and this is true now.
But I won't be tired to keep asking for clarifications on this closing, though. 🙂

The point raised about people on call not knowing Paket is an organisational problem with the Paket user, not a Microsoft concern.
If an organisation decides to use Paket because its listed here but fails to educate it's members/staff on what Paket is...then I believe they have bigger issues than an on call alert!

A good example of having similar feature in the wild - MyGet displays various options including Paket:

See also https://twitter.com/MyGetTeam/status/889937229421957120

I feel that this case is similar to the Rider / .NET Core debugger issue. Huge outcry and muddled communication but in the end all was resolved rather quickly. This is the corporate world, after all. Let people get back into the office and talk it through and I'm sure we'll all be happy in the end :)

@BlythMeister Exactly. And it shouldn't be that hard to state on the site that Paket is a community project with it's own (very good) documentation and not covered by Microsoft's support contracts.

I found out that there exists a document which describes the Nuget obligations towards the community: https://docs.microsoft.com/en-us/nuget/policies/governance
Some excerpts:

because the community always has the ability to fork, the team is fully answerable to the community. The project lead is expected to understand the community as a whole and strive to satisfy as many conflicting needs as possible, while ensuring that the project survives in the long term.

In many ways, the role of the benevolent dictator is less about dictatorship and more about diplomacy.

Generally speaking, as long as the committers are aligned with the project’s strategy, the project lead will allow them to proceed as they desire.

It is a committer’s job to ensure that the lead is aware of the community’s needs and collective objectives, and to help develop or elicit appropriate contributions to the project.

Building community trust in the governance of an open-source project is vital to its success. To that end, decision making must be done in a transparent, open fashion. Discussion about the project’s direction must be done publicly.

The community should never be caught off-guard by a decision by the Benevolent Dictator.

Now, I am aware that

In case of disagreement, the benevolent dictator has the last word.

but with the lack of discussion from the Nuget team side, it is hard to say the dictator here is really "benevolent".

I will not blow into that "paket is so awesome and should be supported"-horn. I think what this issue shows is much more general problem with especially but not limited to nuget: Is it open source software or just shared source?
If its the first then the behaviour of closing this issue with no comment whatsoever is at best ignorant at worst arrogant. In OSS community effort shouldn't be silently ignored for no real reason.
If its the later and just shared source at least make that publicly a statement somewhere that nobody actually wastes time and effort to improve something. If NuGet doesn't want community contributions say so somewhere but don't leave people hanging. If Microsoft wants to own all the tools involved in the official nuget website well thats their decision (even if I don't like it) but it should be clearly  communicated clearly.
The arguments brought up by microsoft so far hint into that direction and just fuel speculations.
As @pmbanka mentions

Generally speaking, as long as the committers are aligned with the project’s strategy, the project lead will allow them to proceed as they desire.

How about simply communicating the strategy so people can understand decisions?

Is it open source software or just shared source?

@coolya the ironic thing is that they answer the question on their website. According to this https://docs.microsoft.com/en-us/nuget/policies/ecosystem, the project is not governed by Microsoft but by the .Net Foundation (!).

NuGet provides a free, open source package management system for the Microsoft development platform. It consists of a few client tools as well as the set of services that comprise the official NuGet Gallery. Combined, these form the NuGet project which is governed by the .NET Foundation.

All contributions made by Microsoft employees are also open source and are donated (including copyrights) to the .NET Foundation.

and .Net Foundation stated goal (https://dotnetfoundation.org/about) is:

We promote the broad spectrum of software available to .NET developers through NuGet.org, GitHub, Codeplex and other venues. We advocate for the needs of .NET open source developers in the community. We evangelize the benefits of the .NET platform to the wider community of developers and we promote the benefits of the open source model to developers already using .NET.

It would be nice to get a comment from someone representing .Net Foundation about the way this issue is handled.

@jongalloway can you help out here?

Disappointing!
Of course MS can add a disclaimer that Paket is not supported by MS.

I recommend you listen to @Krzysztof-Cieslak or you won't hear the end of it :trollface: Nevermind the fact that this PR is useful to many and low risk.

I think at least an answer could be a better behaviour.
Anyhow, since this little PR moved a lot of the people on the community, I would really reconsider the MS position.

The issue is in the ownership of nuget.org by MSFT. Should this have been properly detached - there could have been no issue at all. MSFT should not own the package repository but they can sponsor it by money and free hosting of the feed and packages.

We are working on different solutions and for niw nuget in any version does not solve the lock dependencies and is very slow when you have to update. For that reason we have switch from nuget to paket. IMHO this PR is not a big deal

Introducing new team members to paket is usually one if the first things I do during onboarding. Thus I highly welcome this PR, saving me and my teammates time and showing future team members that paket was not only a esotheric choice done by myself.

Yep dear MSFT, you want to support FOSS so now it's time to act as if it means something :)
Like most of the other consultant, I regret that paket may appear as an esotheric choice just because it does not appear as an official alternative.

Still waiting for a comment from @joelverhagen ...

@Martin521 the issue is already beyond one person responsibility. It's not about Paket, it's about the attitude towards community.

Hello. It's 2017. Welcome to the 21th century.
Politics in IT are an old 20th century habit we should avoid at all cost for the benefit of every developer out there including yourself. We need great tools and we definitely need everybody out there to know about these tools.
On a funny side, to illustrate my opinion: It's not because you want to go on with your beloved Cadillac, - which choice I absolutely respect - that you should deny newcomers in your shop the right to know about Tesla cars. 😉
Let people decide. We'll all sleep better.
You know, we're all grownups here 👍

Show some respect for Paket contributors and people who use this soft and accept this one. The fact that it's not made by MSFT it's even better for you from marketing perspective. I don't buy explanation that all companies on the world will require Paket support from MSFT after this PR. Even if it's true MSFT should educate it's customers how to start using OSS I their projects.

Paket is a great tool. For my use case it allows to ensure each package version is the same across a solution.  Please accept this PR.

Now I know which client to use :)

As someone who works a lot with interns this would be very helpful when introducing them to paket. I would definitely like to see this approved

I don't get it. It's not like paket is some niche tool, it's very widely used. I'd be surprised if you guys aren't using it internally. The explanation for not accepting the trivial PR is "we're not going to point at non-MS tools" or "we can't point at non-MS tools without the approval of someone who shouldn't be making this decision" said with more words.
In fact, if I understand correctly, paket wouldn't even exist if you guys accepted PRs that implemented actual functionality that was needed by an overwhelming majority of your userbase -- let alone accepting two-liners that point people at the tools they're going to end up using once they find them.
Why are you even doing open-source if you're not going to take the contributions your community are trying to make to your ecosystem seriously? It makes it seem like you're doing "open-source" as a form of pandering at best, and a form of getting work done for free (when you approve of it) at worst.
This is the type of behavior that will lead to people abandoning your tools and your ecosystem if you continue it indefinitely, it's the type of behavior that makes people lose trust in you and start wondering if they only use your ecosystem because they don't have much of a choice, rather than because of what you offer that other people don't.
There are talented devs solving real problems with your tools, and in general they'd probably appreciate it if when they took the effort to improve on what you've made, making their work and the work of many other people easier or more robust in a significant way, that you either accepted their contributions after review, provided good technical reasons for why you can't accept their contributions, or were at least willing to publicly acknowledge them when they're basically used by your entire userbase.
If you can't or won't do either, do us all a favor and don't act like you're embracing open source. Stop wasting our time.

@joelverhagen This is an unfortunate stance.  I can understand the avoidance of taking on the responsibility of supporting Paket client usage.  And to a certain extent, the PR itself isn't complete if the only "support" is how to invoke the manager via the CLI.  But, then the response should have been to have a more complete PR, not to imply this really isn't an OSS project.  Not having content that mentiones Paket doesn't stop people from using it; and thus really doesn't stop the effort of support involved in publishing an open protocol.  I think NuGet already has a responsibility to support its protocols since they're open.  Ignoring that does a disservice to NuGet and the .NET communities.

Been using Paket since I started using F# almost two years ago. Totally superior to the NuGet client. VS2017 takes forever installing packages and you have to make sure yourself to use the same package version across projects. Paket just fixes all that. And it doesn't include the package version in the download folder path either.
Why wouldn't you want to promote different tools? Showing some diversity might even make the .NET platform more attractive.

Glad to see our community behind this PR, paket is a nice tool and this integration would definitively profit to both parties.
Keep posting !

Using paket at work for multiple projects. Also actively giving courses both internally in the company and externally, showing usage of modern tools, paket being one of them. Having this on nuget site would be very helpful. Please reconsider and merge this PR.

Ok. Seems this may have gotten quite out of hand, and many people may have missed the original point of why this is got a lot of heat in the first place.
The reason why this got a lot of heat was because the issue was closed after some questions were asked; everyone wanted more discussion but were felt like they were purposely ignored. It would have been better if the issue was closed right after the first comment.
Just realize that there are people on the other side too that will read and have to deal with this, by ignoring or responding (I hope it is the later).
As for me, I support Paket and do wish Microsoft and/or the NuGet team see it as a positive tool for the ecosystem. But, if we were to see it happen, we need a healthy relationship from both sides.

@TIHan you're right, the debate needs to stay positive and not personal (which, by and large, so far this has done). I do also think though that it's important to remember that there aren't really "two sides" in this issue, for two reasons: -

There's basically 99% of people on here supportive of both the original PR, and also in agreement that the issue shouldn't have been closed in the way it was (FWIW, I think that if this had been immediately closed, it still would have generated some heat).

This isn't a "two sides" issue (which also implies a zero sum game). It's the same one community: the .net community. IMHO, there's no winners for anyone in the community with the current situation.

But yes, I agree it's not necessarily about whether Paket is "better" or "worse" than NuGet - it shouldn't even be about that primarily. What's important is that Paket is an alternative NuGet API client that a not-insignificant (and growing) section of the .NET community use. There's no reason - IMHO - to continue ignoring it on the site.

Dear Nuget Team,
On a daily basis, people here among us work on very serious issues, which issues will eventually benefit the whole humankind and maybe even the whole planet. You, me, everybody
So these people just need the best tools out there to do their job. They need to think fast. They need to code fast. They need to go fast as possible for the benefit of us all.
When you deny the right to promote a tool that is known to boost every projects, including the kind of projects that may eventually save our lives, you do take an overwhelming responsability on your shoulders.
We're all on the same boat.
But I have faith that whatever blocks you from releasing this PR will eventually fall down under so much common sense.
So I wish to thank you in advance for taking this matter very seriously for the benefit of us all and make this world even better 👍
Sincerely,
Your fellow developer.

@isaacabraham I agree it shouldn't be ignored; but nobody is obligated to do anything. It is entirely up to the NuGet team to do what they think is best, even if in our eyes may not be the best. All we can do is accept it and do what we can to help them in any capacity. And hopefully we will all have more constructive discussions in the future.
I do see your point that there are no winners here; either we all win or lose. What I meant from "both sides" was, the NuGet team and people not on that team.

@TIHan

All we can do is accept it and do what we can to help them in any capacity.

I would totally accept the decline of a PR if there are sound technical reasons or at least a sound explanation and openes for civil discussion; been there, done that. But if my work, mostly done in my free time, is rejected intransparently because the maintainer just feels like it or has a hidden political agenda then I wouldl totally refrain from helping them any further. And as @isaacabraham has put it. It should not be two sides but one community. The NuGet Team is part of the .NET Foundation and as such should adhere to it's own principles. The reasons given in @joelverhagen 's original comment were not reflecting the commitment to community and OSS that the .NET Foundation claims to stand in for and in many projects does so.

but nobody is obligated to do anything. It is entirely up to the NuGet team to do what they think is best

I don't believe this is true, based on the "NuGet governance" document (https://docs.microsoft.com/en-us/nuget/policies/governance). According to the document, Nuget team is supposed to work together with the community.
Moreover, if I understand correctly, this projects is governed by the .Net Foundation (https://docs.microsoft.com/en-us/nuget/policies/ecosystem), so the way the issue is handled is in fact a concern of .Net Foundation. The Foundation was asked for a comment several times in this thread and on Twitter, but there was no official response yet.

All we can do is accept it

We can also show our disagreement with @joelverhagen decision, e.g. by writing in this thread and contacting members of .Net Foundation (like @jongalloway) asking them for a comment. I think it is better than simply giving up.

They still haven't responded? Wonder what it would take to do all this without Microsoft.

I can believe that Nuget administrators decided not to merge this PR, and moreover close this topic without further explanation. Completely unwise decision from your perspective - that's why people move from Microsoft to other more userfriendly environments.

@voronoipotato You could use a more supportive platform such as MyGet.org instead, which does list alternative clients such as Paket

I can see this is one that can't be merged without some internal discussions happening at Microsoft. I do hope they will be able to do that soon and reach a positive outcome for the community.
Just last week at work we were discussing how paket could help solve some dependency management issues that we see with nuget. Unfortunately paket wasn't yet seen as a sufficiently standard solution. Would have helped the case if it had been more clear to everybody how paket works with nuget feeds. I.E. it would have helped if this PR would have been merged.
Meanwhile... the dependency management problems continue to be an issue for .net projects in our company... Other projects are choosing Linux and jvm languages... There's not much .net stuff on our corporate tech radar...
Microsoft I think you can either attempt to maintain control of a .net ecosystem as it shrinks, or you can embrace your community before they move elsewhere...

I don't normally get involved with MS to OSS discussions as its a complicated relationship.
In this case I have seen Paket, which is a solution to design flaws in NuGet, ignored or mistreated by MS a number of times.

https://preview.nuget.org/ seems to have a "Let us know your feedback" link in the page which leads to this: https://www.research.net/r/XP9GS73

So what about this PR from @forki
not even a comment since 10 days and still open
i just hope that nuget adapt, it's 2017 wake up
event if there's good reason to refuse this PR then "adapt or ...." nuget is barely useable as of today

Same about mentioning Rider - https://github.com/NuGet/NuGetGallery/pull/4089

After 11 days of ignorance, it became obvious that there is something generally wrong wih Nuget team. Guys, really, why did you move to GitHub? Why you just not make this repo private and do it all privately? Why pretending you are part of "brand new OSS-like Microsoft", if you cannot write single comment explaining your decision? It is not only rude and unpolite, it is also giving signal to really skilled devs like @isaacabraham that you do not care about their work.
Please, stop thinking in barriers and just do single small but important step: Start to communicate. We are all member of the same .NET community after all.

Nugget team,  how do you think this will end? Do you think people will stop posting and act like nothing happened here?
My guess is people (me included)  will start to become tired of this situation and ultimately Microsoft (not just you) will lost a lot more than just a contribution.

Avoiding communication on this issue can hurt .NET ecosystem by misleading developers into the perception that that's how .NET "Open Source" works.
Please, talk to us.
Please, explain your position with regards to NuGet governance and .NET Foundation.

@Krzysztof-Cieslak Interesting enough that Microsoft does mention Rider on their content pages regarding .NET development. So this is clearly not a policy "not to mention other products" but something specific to NuGet, may be?

When I see this, I thank god I switched to FOSS stack few years ago: ruby and golang. Bye, Microsoft!

@Krzysztof-Cieslak shhhhhhh, you're ruining the illusion of community acceptance.

so the real question is how nobody trying to ping Sateya here or on twitter because it seems the nuget seems to move at the complete opposite of the collin ovation i tend to here from him

@tebeco He was mentioned in a number of tweets about this issue.

Evil me is both happy and disappointed

@isaacabraham:
State of this illusion right now:

Nuget team atm:

FYI, I posted some questions regarding this issue on the .NET Foundation forum. http://forums.dotnetfoundation.org/t/foundation-governance-over-nuget-project/2690

Brutal. I've pinged important people on Twitter and brought the issue up on LinkedIn and Facebook.

@adymitruk Thanks, although I think that important people are already aware of this :-)

@Dzoukr I think abusing anyone is not a good idea. There are reasons, most probably political, why Nuget team behaves this way. But they are probably the last ones we can blame for this.

@alexeyzimarev Agreed. Don't forget that ignoring people is a form of abuse too so this is advice for all.

@alexeyzimarev The best fight with ignorance is humor. It is not abuse at all. You miss the point - the critic is not about rejecting PR, the critic is about not communicating with community, about not explaining, about behaving like this. As said @creyke : "ignoring people is a form of abuse".
This would be ok, if NuGet team would do it in private repo with no contribution allowed (like old days). But saying "we are the new open-source friendly" and behaving like this... well, meme reacting is actually the nicest you can get.

I think that this PR would enhance both Nuget and the .NET ecosystem.  So, please accept this.

This is a real bummer. Paket makes reliance on dependencies via NuGet a better experience.
Seems a shame to try and hide it from developers who wouldn't otherwise know about it; why not instead include and welcome it as an alternative? It's got some different behaviors/features that the official NuGet client could definitely benefit from adopting.

Accept or reject. All good and obviously very personal decision of maintainers. But no communication is no good for the company try to build their OSS reputation on ashes of historical blunders in this area.

I've spent best part of last ten years persuading people from non Microsoft backgrounds that dot net is really headed in the right direction and that OSS has been embraced.  Paket is the only package manager we use for all out dotnrt projects.  This really is childish.  Work with your ecosystem to make something better. The alternative is far far worse.

Really detailed blog post about whole situation by @isaacabraham: https://cockneycoder.wordpress.com/2017/08/02/some-words-on-nugate/amp/

In case anyone at Microsoft or anyone on the NuGet team doesn't comprehend the severity of this and thinks it's just a minor flare-up that will die out; I just want to say that, for me (and I suspect 95%+ of the developers who come across this thread) this is catastrophic for your goodwill and reputation.
The behavior on display is unbelievably rude, unprofessional, and appears to be downright hostile towards the .NET community. And if you don't understand why such a small, seemingly insignificant issue is so significant, then that is part of the problem.
I found this issue because Google Now promoted it to me in my news feed on my Android phone. Consider how far this is spreading. Please apologize to @isaacabraham regardless of whether you ultimately succumb to reason and reopen/accept this PR or not.
I hope this has just flown under the radar of the team which resulted in everyone getting the wrong impression; but given the length of time that has passed and the amount of commotion this has caused, I'm doubting it. I really hope to be proven wrong.

Presumably waiting for the Streisand Effect to kick in.

https://twitter.com/msdev/status/892490124545708032

Thousands of #developers use, contribute to, & release #opensource at Microsoft every day. Join us on GitHub: http://msft.social/NGekWM

Well they should have added: contributions are accepted as long as they fit to internal politics and our very personal agenda.  😞

I don't know who owns it, but check out nuget.com :P (thanks @kot_2010)

Open source doesn't mean the community gets full control over features and you should all know that by now.  If @isaacabraham had a feature request he should have done the proper thing and opened an issue to focus the conversation there instead of submitting a PR with no context and no description.
Those of you complaining about lack of communication should reread @joelverhagen's comment.  Disagreement with his rationale doesn't mean he owes you a debate on the subject.

@jpdillingham

Disagreement with his rationale doesn't mean he owes you a debate on the subject.

I think you will find this document interesting: https://docs.microsoft.com/en-us/nuget/policies/governance
I think the last section (Transparency) clearly states that the Nuget team indeed owe us (the .NET community) a debate over this higly supported PR. Some excerpts from the document:

However, because the community always has the ability to fork, the team is fully answerable to the community.

Discussion about the project’s direction must be done publicly. The community should never be caught off-guard by a decision by the Benevolent Dictator.

@pmbanka fair enough.  I retract my previous statement.

@pmbanka Also from the Transparency section of https://docs.microsoft.com/en-us/nuget/policies/governance

The community should never be caught off-guard by a decision by the Benevolent Dictator.

I don't use Paket but I cannot help but see (reading all the comments here) and feel personally (based on 10 years working within the .NET ecosystem) that this decision and how it is being handled has caught the community off-guard.
Hopefully the current, uncomfortably long lasting radio silence is due to the need to involve higher level officials in making a key decision in the future of NuGet and open source at Microsoft in general. This issue surely strikes the marrow.

Just consider that if this PR or a similar one is accepted, then it will be that much more difficult for the NuGet team to refuse a similar request from another person or organization. JetBrains has their request in for Rider, for example, a product that competes with other Microsoft software. Or what of Joe Blow's package manager? It could be awful or wonderful software, but who is to decide what should and should not be accepted. The NuGet team would surely like to avoid having to make controversial decisions like these, and would much prefer procedural, even mathematical processes. Closing anything that is potentially controversial, politically charged, or perceived to negatively affect the bottom line of some other Microsoft product is an understandable stance. Failing to provide a response that clarifies expectations in situations like this is not understandable, and only leaves a vacuum that is currently filling with speculation.
This is an interesting moment in Microsoft's history. The outcome of this will affect my perception of Microsoft and what Microsoft means by "open source." NuGet is such a core part of the ecosystem and community. How it is handled will ripple through everything else.

@jeremycook you write it like this is something unique in the world.
What would you say about this:

or this:

or even this?

Or, if you want references to Microsoft, this:

@jeremycook NuGet team is governed by .NET Foundation, which declares certain obligations towards the community and transparency. Even the code is donated to .NET Foundation.
According to this governance I don't see a reason how and why should the Microsoft have more say on this PR than the .NET community.

@abdullin  the .NET Foundation doesn't get to tell the NuGet team how to run the project, which they (the NuGet team) are the maintainers of. The Foundation is just the legal holder of the license & intellectual property, not the org who actually does the programming. Ultimately the programmers have the final say in what does or does not happen.
If you wanted to send in a PR to the XUnit project (another .NET Foundation project) adding Mono support and Brad Wilson closed the PR saying "nope, not interested in supporting this" you wouldn't be able to change the outcome by opening a discussion on the .NET Foundation forums and appealing to their leadership. That's not how it works. The maintainers still have the ultimate veto on what they want to support and what they don't.
What the .NET Foundation can do, however, is facilitate a conversation about how MSFT should be working with its OSS users / contributors in order to actually have an OSS community around it.  Ultimately though, it's still up to the maintainers to choose how they want to use their time and resources.
Set your expectations accordingly and don't expect to be able to override the NuGet team. That's not going to happen and frankly nor should it - the programmers who actually do the work get to vote with their feet and that's how it should be.
There are a lot of good reasons why the NuGet team should consider this PR. Improving the adoption of nuget.org packages, fostering the development of a tooling ecosystem on top of / around NuGet, etc...  Maybe the leadership of this project unable to see the forest from the trees or maybe there's panicky lawyers wringing their hands about endorsing OSS tools and liability, lawsuits, clean IP, giant asteroid heading towards earth blah blah blah... Whatever the case may be: you're going to get a better result by trying to appeal to the business value of this PR and the signal that merging it would send to the rest of the community. That case has been made strongly by others on this PR and the NuGet team should really, actually consider it without brushing it off.

@abdullin well said, and yes ideally Microsoft's interests will not trump the project community's interests. I guess myself, like many posting here wonder at the utter silence despite the unprecedented (I infer) community feedback.
Ideally governance will do its job. A key part of that governance is community involvement and the voice of the community expressing its desires, and the hardest form of governance in open source, which is the ability to fork. (Not that I'm suggesting this deserves a fork, it does deserve further consideration and communication from the NuGet team.) And so it may not matter that 4 of the 7 members of the .NET Foundation team listed at https://dotnetfoundation.org/team are Microsoft employees: Miguel de Icaza, Scott Hunter, Robin Ginn, Beth Massi all huge contributors to the Microsoft ecosystem, all Microsoft employees. But it also might matter at least a little in very specific circumstances because those individuals answer to others at Microsoft and if their benevolent dictators do not like the direction the .NET Foundation goes, a strategic move, it could lose support from within Microsoft. Governance comes from many directions, some of which are not always found in explicit, well articulated documents.
Thank you for your immense contribution to Autofac, BTW. A project worthy of membership in the .NET Foundation.

@Aaronontheweb from my perspective this is utterly incorrect comparing project like xunit.net with nuget.org. Nuget.org is the only public official package repository for the whole .NET community. Xunit.net is one of the testing frameworks. Don't like it, need Mono support - do seek elsewhere. This won't work with nuget.org. Plus, the PR was not closed because developers do not want to support some feature or platform, which apparently would require additional work in the future. No, this is a small PR with a couple of lines, in the HTML template. And it was closed argumenting towards the only two nuget clients made by Microsoft, made by Microsoft employee, who is eventually also a developer at Nuget, which, in its turn, is not own by Microsoft.

@Aaronontheweb thank you for clarifying the distinction between the project team's role and the foundation that backs it. That is helpful to how I think about this. I certainly don't want to misappropriate responsibility.
Would it be correct to say that the .NET Foundation's has no obligations in situations like this?

@alexeyzimarev "that's like, your opinion, man."

Nuget.org is the only public official package repository for the whole .NET community

If you want there to be some diversity in terms of package sources, start buying some subscriptions from myget.org so they have the resources to compete with nuget.org. That's voting with your feet and will accomplish more than additional comments on this PR will.

@alexeyzimarev yes, not unique, but ultimately this is the NuGet team's decision, which at least makes it distinct.

@jeremycook https://github.com/dotnet/home/blob/master/governance/project-governance.md#decision-making - basically it's up to whatever structure the maintainers chose. This project is under the benevolent dictator model AFAIK

Will the foundation influence the technical direction of its projects?
There is a Technical Steering Group that facilitates coordination between projects
Individual projects act independently of the foundation

How are .NET Foundation projects governed?
Having a clear governance model that describes how individuals and organizations can engage with a project and how decisions are made is an important since it helps ensure transparency within the project. The .NET Foundation does not prescribe a governance model for its projects. However, we do work with projects to ensure that they define and document an optimal model that matches the community’s objectives.

https://dotnetfoundation.org/faq

@abdullin I withdrew my comment because It's clear that the project acts independent of the .NET Foundation. Microsoft's interests trumping community interests in this project is still an open question that I hope will be explicitly addressed, but there's no need to point to the .NET Foundation as a source of that influence. Thanks for your comment.

@jeremycook @Aaronontheweb Thank you for updating me. I've adjusted previous comment accordingly.
Although NuGet maintainers ultimately call the shots on their project, it would still be nice to hear back their side of the story.

@Aaronontheweb well, I am both paying private and enterprise user on MyGet, what else shall I do? Start buying even more?

@alexeyzimarev tell your friends!

I didn't comment on that PR yet because I didn't have any new thing to say but I want to point to the JS community for an example of doing it well:

When facebook created yarn, the npm blog announced it, with very nice words http://blog.npmjs.org/post/151660845210/hello-yarn

As I said at the start, we’re happy to see Yarn join the ranks of open source npm clients. This is how open source software is supposed to work!

Sharing the fruits of their labor will allow ideas and bugfixes to flow back and forth between npm’s official client and all the others. Everyone benefits as a result.

We’re pleased to see Yarn get off to such a great start, and look forward to seeing where it goes.

NodeJS is currently listing Node-ChakraCore (A fork created by Microsoft) on it's official download page https://nodejs.org/en/download/
The fork isn't even fully stable yet, and they don't support it directly but they still direct their users to check what else exists around their ecosystem.

Let's hope that one day Microsoft will stop the NIH-Syndrome/PR-Speak and allow a real OSS community to grow around their projects.
Not consumers or users of OSS code drops but members of a community.

@baronfel I hate to burst your bubble, but Maven/Apache doesn't give you directions on how to use other clients with the Maven Central Repository.

Apache Maven is both a Java project manager and dependency resolution tool.
Maven Central Repository is the main repository for Maven packages, but as you can see from that link, has no actual website other than a web accessible file listing.
mvnrepository is a third-party search tool for Maven Central.  One of several.

While we wait, could we incorporate this PR in some sort of browser extension?

Hey everyone,
I run the NuGet PM team at Microsoft. There really is no good excuse for us to be so slow to reply to this thread, and for that I am really sorry. We are very close to shipping .NET Core 2.0, and it has been all-hands-on-deck for the .NET and NuGet teams, which was a factor. But please allow me to explain some additional context around the delay in our initial response.
NuGet.org usage is growing fast, it has had about 3x growth in package downloads in just the last year. This is fantastic news for the .NET ecosystem, but it also means our security profile is getting larger. We are evaluating a variety of measures to further shore up NuGet’s security; for example, we are looking at requiring submitters to sign packages and clients to respect signatures. Some of the security changes we’re looking at for both the NuGet client and the server are in development. The list of measures we’re considering is long, and we don’t have a solid proposal to take to the community quite yet. But we plan to share a proposal with the community  on our blog soon.
Some of the changes we’re considering are potentially destabilizing and could imply breaking changes to the protocol, increasing the friction of the submission process, and so on. We felt we needed to completely understand the changes we needed to make to the various NuGet.org protocols to support these scenarios and that until we’d thought it all through, we should keep the universe constrained. For that reason, we thought it  best to limit the number of clients we list on the website.. What we do not want to end up doing is to do a backflip on the policy on which clients are included.
There has been a lot of excellent suggestions and commentary on this thread, as well as a few entertaining GIFs. We clearly acted in haste when we closed this pull request in trying to clear out our backlog  , and that felt like silence to the community. However, here we are now and we want to make things better. This PR highlighted the fact that we hadn’t discussed how we should think about other NuGet clients. We will spend some time thinking about our approach, and I have created a GitHub issue for further discussion https://github.com/NuGet/NuGetGallery/issues/4510.
Thanks for the civil discussion on this topic  and keeping us accountable, and we look forward to working through this with you.
Thanks,
Unni
NuGet Team

@unniravindranathan First of all - Thank you for coming back to the discussion and providing some more context.
I'll think out loud here but since NuGet is part of .NET Foundation I don't really see how it could be an issue that the ecosystem is growing from a clients perspective - If they comply with the spec, wouldn't it even be better if there are more and more clients supporting NuGet on its own?

@unniravindranathan: Am I right that:

There are going to be breaking changes to NuGet protocol that will cause older clients to stop working
You don't want the situation when NuGet Gallery is listing X as available client but it does not work because protocol changed and X is not updated yet to support new protocol

increasing the friction of the submission process,

Do i understand correctly that you want to make creating new packages harder?

@tomkerkhove Yes, we want that as well. You will see us move in this direction, starting with documenting our v3 protocols. We will also be setting up a more open forum for proving feedback on our backlog and progress, as well as discussing the approach to the linked issue - likely a NuGet contributors slack channel.
@Novakov We will be more transparent in brainstorming and sharing information before we finalize any changes to our protocol - something we have not done well before, and we will fix. Hopefully everything can be done in an incremental way without breaking clients, but almost certainly, we will want enforcement of newer clients - which you could think of as a breaking change. Also, in everything we will do - we will make sure that the workflow o creating packages remains smooth and familiar.

If there is any brainstorming on the protocol going on, I'd love for the community to be involved. There are quite a few others running a server, a couple of clients, some who are both, and pretty sure they all have experience with the needs, pains and ideas from their respective users.
And who knows, perhaps some random NuGet package author or consumer may have a brilliant idea (I remember a recent discussion on package signing where the author even developed a PoC to discuss, unfortunately resulting in no discussion at all).

Good example on this how the .NET and ASP.NET teams do their internal discussions (posting mtg mins, video recordings, etc) online :+1:

As has been said (both here and by me already), thank you for replying - we can now have a discussion in public that everyone can participate in.
Whilst my original PR was limited in scope and aims, clearly a more broad concern has been identified i.e. community involvement in NuGet in general.
The original PR
I'd like to leave that issue to one side for a moment, and roll back the scope to the original PR itself. It's not about changing the world. It's not about getting the NuGet team to sign a contract that Paket will be supported for the next 10 years by MS. Nor is it about whether Paket will conceivably be allowed to upload packages in the new secure NuGet API that is about to be designed and developed over the coming weeks / months / years. The PR is about a new tab that makes it easier to add packages with Paket. Nothing more, nothing less.
NuGet Security and Paket
Whilst I understand security is important, I really don't understand the relevance to this PR. Your concern appears to be about introducing breaking changes that could leave Paket broken. Paket is being used, right now, by lots of people. Lots of commercial .NET projects already rely on Paket. Whether or not the PR is accepted will have virtually no impact on that whatsoever – those organisations and individuals have elected to use Paket anyway. And more teams and organisations are going to use Paket regardless. So, the problem of the security issue for third party clients isn’t going to go away simply by rejecting the PR. It’s already an issue.
Secondly, Paket has been playing catch-up with NuGet server changes for a long time now, and we’re used to dealing with what is essentially a moving target. It’s a testament to Steffen and many of the other 200 contributors that the project has that the team are able to react and respond very quickly to the myriad of undocumented breaking changes that occur in the NuGet API on a regular basis - sometimes fixes to Paket are pushed out within hours of NuGet server changes.
Besides, there's nothing to stop you preventing any future changes, right now, breaking Paket by (as you rightly say) start to communicate more regarding upcoming changes - a great point. Indeed, I raised https://github.com/NuGet/NuGetGallery/issues/4088 nearly two months ago to highlight this very issue.
I think it could help matters greatly by stopping treating the NuGet Server and Client projects as a single entity, with hidden communication from the rest of the world. Treating the server API as a real public API (with things like versioning and release dates etc.), with a publicly planned roadmap that all clients - including the NuGet client - develop against, could alleviate many of these problems. Compare that to the current situation where's there’s ostensibly a public API, but changes occur with little or no warning to anyone, except the NuGet Client team.
If this security change is properly planned and documented, and we’re all able to work together on this, there should be no issue with breaking any client whatsoever – I’m sure that Paket team can update the code to work with whatever security implementation is agreed upon.
Conclusion
So, yes, security is important - I'm not denying that. But, IMHO, that's a completely orthagonal concern to this PR, and trying to conflate the two (and add an issue on a separate repo) doesn't make much sense to me at all - it's just muddying the waters.
I really don't want to come across as difficult. I just don't get it - sorry.

@unniravindranathan
Thanks for the reply! But to be honest, I'm still confused to find the lines or to connect the dot between the original issue and your reply.
First, Paket is developed independently and afaik it has no support from Microsoft at all and I'm aware that Microsoft doesn't have to support it. Therefore this PR should be reconsidered, a simple reply of yes or no with easy-to-understand reason would suffice in my opinion, not just closing it without definitive reasons on why. Because I still can't fully understand the reason of explaining that MS is tied to the stringent deadline to prepare .NET Standard/.NET Core readyness so it should be understandable to have prolonged silence...
I'll try to explain my confusions below..
Based on these sentences:

We felt we needed to completely understand the changes we needed to make to the various NuGet.org protocols to support these scenarios and that until we’d thought it all through, we should keep the universe constrained. For that reason, we thought it best to limit the number of clients we list on the website..

Does your reply imply that Paket as nuget client should/must obey because of avoiding chaos or changes in the way of nuget protocol itself? Even Paket itself has been finding difficulties on the way some packages are released, such as this package from Microsoft's ASP.NET team:  Microsoft.AspNet.WebApi.Client in https://github.com/fsprojects/Paket/issues/2495 and some other non-MS packages have other issues as well, especially when handling dependencies.
Therefore, put it simply, Paket has shown respects the existing nuget communities, not dictating nor changing it. Also please take a look on numerous issues in Paket itself has to be handled based on these inconsistencies and difficulties when supporting other nuget servers.

Some of the security changes we’re looking at for both the NuGet client and the server are in development. The list of measures we’re considering is long, and we don’t have a solid proposal to take to the community quite yet. But we plan to share a proposal with the community on our blog soon.

Then if there's a need for unification of security protocols for both client and server, why is this unification coming now? Again, afaik Paket tries to support many cases on many nuget servers out there, not just from MS nuget server but from third parties such as MyGet. By quickly comparing this issue to Myget co-operations, this prolonged reply proves to me otherwise, and I'm trying to be honest here.
If you want to, I will continue to discuss on #4510 as well. But still, I hope I could get a simple answer and reason for this. Or I might miss something...

@unniravindranathan if everyone sees the NuGet team won't accept this kind of small improvement PR to the documentation, they do expect the same treatment for larger security fix PRs. So now the community won't have  interest to fix the security problems NuGet has.

@unniravindranathan:

we closed this pull request in trying to clear out our backlog

What? Is closing PRs without merging your team's way to clean backlog? XD

@unniravindranathan said...
likely a NuGet contributors slack channel.

As mentioned in this issue (https://github.com/NuGet/NuGetGallery/issues/4088), I think an announcements repository, similar to what other Microsoft Teams use would be a better idea.

@gep13 , not only Paket which is an opensource tool - look at https://docs.microsoft.com/en-us/nuget/policies/ecosystem#non-microsoft-projects . Over a dozen tools listed there. I hope the case is not that commercial vendors get access to API changes and OSS developers does not...

@unniravindranathan firstly, :+1: for keeping the conversation going in a situation where it might have been seen as safer to bury heads in the sand. Thank you enging with the community in precarious discussions.
For the record, I'm not currently a Paket user. But as someone who has no stake in this (other than being a fan of both .NET and OSS, and thinking about the concept of .NET OSS maturity models), I see a few potential issues with the current course of action:

There is a friendly alternative available to the current path -- accept the PR and remove this tiny bit of code if it later becomes incompatible with security. This way, everyone wins -- Paket users know that you support them and an open community, and you have zero liability or requirement to support should anything evolve that complicates it.
We're missing the opportunity to embrace a community partnership. Let's say this tab is added now and then security-related changes force its removal. Wouldn't that represent an opportunity to open the upcoming roadmap of changes and allow Paket's users / contributors to adjust well in advance? Alternatively, I think it would be reasonable to say "we have to (temporarily) remove this tab until security-related changes are complete."  I don't think many in the Paket ecosystem would disagree with this, especially given the comments.
It shows that the roadmap isn't public, which will backfire. Given that this other ecosystem exists, should the roadmap have future breaking changes, would those be released with no warning to existing Paket users, affecting their ecosystem as well?
It leaves visible and vocal users feel that they have no input on direction. For users who are this passionate, opening roadmaps and future plans would be met with gratitude. Instead, MS appears to be squandering that good will. .NET Developers want a say in their future and are willing to work toward it. Seems worth embracing.
It forgets the situational context. Microsoft has has a long and...varied 🤔 .... journey around OSS code and projects. In some cases embracing them, in some cases directly competing with. Given Microsoft's history with NIH, it's fair of users to feel cynical about something like this. There's something of a gap to be closed in terms of embracing the spirit of open-source, and setbacks like this have ripple effects across the ecosystem in terms of the optics of MS's approach to OSS. The assumption of good faith on MS's part towards open-source is budding, but make no mistake, it's still tenuous.

Thanks for continuing to engage; I hope you'll consider my points.

@psmulovics said...
not only Paket which is an opensource tool

Oh, absolutely. I was simply using Paket as an example given the original topic of this PR.

I think @SeanKilleen nails it. As he said:

accept the PR and remove this tiny bit of code if it later becomes incompatible with security

I would have liked (would still like) to see this merged because it provides immediate value to a large number of users. I'm all for stability, but the counter argument of not merging this in fear of some future change that may or may not impact the referenced project seems overly cautious IMO.

@isaacabraham I totally get that the change to include Paket is small. But I do want to make sure that we're being fair to all NuGet clients. I suggest that we use https://github.com/NuGet/NuGetGallery/issues/4510 to further discuss the criteria we want to document for including clients in the future. Reed makes some great suggestions that can be a starting point, but I want to make sure we get feedback from the Paket maintainers as well. We should also discuss additional changes the NuGet team would have to make to have a set of extensibility points that we had not previously thought about (such as a disclaimer about the support from our team for the additional tabs, a link to a landing page in your repository so users can read more, etc.).
Please do note that it will take us some time to write up a final version of the proposal, so thanks for your patience in the meanwhile.

@unniravindranathan I'm personally much happier with your most recent post. For me, it's about fostering OSS within the .NET ecosystem, and making sure that key projects (like NuGet) are doing things to support the community, not hamper it. I'm obviously happy to try to help discuss and hammer out requirements, etc.
In that vein, I'd like to make a recommendation:
Reopen (but don't merge now) this PR, with the expectation that @isaacabraham or another Paket enthusiast will update to match any requirements decided upon in #4510. If, at the point where a final decision on requirements and proposal is formed, Paket does not qualify, close this then, with the appropriate rationale in place for why this is being closed.
That would send a message that this is being actively worked on, and not squashed. It also sends the message to the community that contributions are welcome, even when the timing isn't necessarily convenient (ie: somebody opened a can of worms you hadn't expected, like this!).
I don't want to speak for other people here, but I suspect that people will be happy with being patient, if there is a strong message that progress is being made, and that their contributions, and the things that are important to them, aren't being ignored for the wrong reasons.

@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.

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.

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.

Also #4510 feels like an attempt at the slippery slope fallacy: if we let this PR in we'll suddenly have 800 tabs as every man and his dog adds their own client, therefore we can't add one extra tab. MyGet added Paket and they have 7 tabs, not 800.

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

Chrome Web Store link
Github Repo

Figured a little levity doesn't hurt here.

@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.

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.  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.

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.

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!"

It is crazy.

@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 ?

Please reopen this.

Update: The criteria was defined as part of https://github.com/NuGet/NuGetGallery/issues/4510 and the required changes to enable third-party tabs is done now. Please refer to the associated PR on the issue: https://github.com/NuGet/NuGetGallery/issues/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.

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

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

@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.

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! :)

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

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

@isaacabraham I will rather have you do the honors this time ;)
Please feel free to close this one since the other PR:https://github.com/NuGet/NuGetGallery/pull/4638  is out.

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

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

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

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

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

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


Example turtle and figures are updated

I have updated the example turtle files further. I replaced some of wrong sio URIs and I have updated turtle for some modules. The figures also updated to reflect example rdf changes

I have updated the example turtle files further. I replaced some of wrong sio URIs and I have updated turtle for some modules. The figures also updated to reflect example rdf changes

Hi @rajaram5 I also updated the person.shex. I noticed that you moved 'my' person.ttl to sio-model/ folder. Could you do the same with the person.shex for consistency bf merging the PR pls?

@NuriaQueralt I fixed the PR issues. Can you have a look at it please?


tests2png is defeated by TestScheduler#run()

Bug Report
Current Behavior
As part of #5019, I discovered that the tests2png script currently (as of 1b2021f) renders the following PNG images as only the operator and no observables:

audit
auditTime
buffer
bufferCount
bufferTime
bufferToggle
bufferWhen
catch
combineAll
combineLatest
delay

Example

Diagnosis
I did a git bisect and found out that the issue is introduced by multiple commits. For audit, the behavior started in c41d00b. For auditTime, it's broken as of bc91ba0.
This suggests that the problem is the introduction of TestScheduler#run().
Environment

Runtime: Node v12.11.0
RxJS version: 1b2021f

Still seeing this on master as of d2f68db3.
Pinging @JWO719 for visibility.

Still happening with d7f70782.
Additionally, I had to npm install ts-node tsconfig-paths -D first.
I guess the diagrams haven't been receiving a lot of love recently?

The diagrams definitely didn't received a lot of love in the recent time, that's true. Sorry for coming back this late to you. To be honest, I kinda lost track on the issues with the marble diagrams in general. Is there anything I can support you with, because I would really love to have the improved marble diagrams you worked on?

I won't be able to take a look for another couple of weeks due to medical reasons, but I think it would definitely help to have some form of documentation on how the testing APIs changed. Perhaps the tests' authors could share an explanation?

This topic kinda poped up again. Sorry I didn't respond in the meantime. I'll take a look and when I am stuck connect to the people that might can help here

Just to be totally clear, so besides the operator listed at the top, it is working properly in the current state?

With 02f458d, in addition to the operators in my original message, the following now also render empty:

concat
concatAll
concatMap
take

I also still had to npm install ts-node tsconfig-paths -D on a clean repo before I was able to run tests2png.

Ok great I will have a look at this tomorrow and come back to you!

FWIW, the asDiagram function that's used in the test is declared here - in the Mocha context - and it uses the diagram function that's only made available when the diagram-test-runner is used.
It doesn't work because it depends upon using the assert function passed to the global - 🤮 - TestScheduler instance and that instance is not ignored by tests that use TestScheduler#run.
IMO, this asDiagram infrastructure should be abandoned in favour of using swirly, some input files and a script. Maybe that's what Ben was referring to in this tweet. I sure hope so.

I would be very fine with that. That sounds actually like a pretty good idea

Also, Ben has been deleting the asDiagram stuff in his changes to the tests, so I doubt anyone will be sorry to see it go.

Ping me if you need any help interpreting Swirly's API. You can probably figure it out by inspecting the call to drawMarbleDiagram but I'm happy to assist.

I think this can be closed for now as we will use swirly to manually create the svgs. POC is already in master, we just need to create new marble and update the image refs.

Looking forward to it!


Async SDK

An async API for the SDK would be highly appreciated. For any kind of production application, not allowing the web server to handle requests while we are waiting actively to respond is crucial.

Closed. This feature is now available.


GH-35143: [R][C++] Fixed shape tensor causes broken build on OSX

Rationale for this change
std::reinterpret_pointer_cast was introduced with FixedShapeTensor PR (#34797) but is not available on OSX (see #35143).
What changes are included in this PR?
This change switches to using internal::checked_pointer_cast.
Are these changes tested?
Change is tested in CI, but should also be verified on crossbow.
Are there any user-facing changes?
No.

Closes: #35143

@github-actions crossbow submit verify-rc-source-cpp-macos-*

@github-actions crossbow submit r-binary-packages

@github-actions crossbow submit r-binary-packages

@paleolimbot mac builds now pass.


"Assign Input to Mix" not working on QU16

Hi,
With the QU-16, the Assign Input to Mix / FX Send is not working.
For example the following configuration:

Doesn't change the Mix Send for CH 1 on Mix 1
Assign Input to LR / MuteGroup / DCA does work, however.
For example:

I am experiencing the same issue with the 'assign input to mix' not working, but 'assign input to LR' does work.
I'm running [3.2.2 (3.2.2+6688-stable-7417d2a0) linked to a QU-24.
If anyone has been able to resolve - please let me know your workaround!


Add Tags, Globals and Assets support

Release 0.9.0 should see Tags, Globals and Assets support.

Would love to see tag import support! I'm just getting started with Craft, but will be migrating from another web app where the entries have tags. The plugin looks great for the rest of my needs...except for tags. Keep up the great work!


download in Excel

SQLPad is great!!!
One suggestion: SQLPad already have csv download option. Could have excel option too? This will eliminate one step, save in csv, import to Excel, send to user. There are this guy here:
https://github.com/mgcrea/node-xlsx
Very nice and simple.

Thanks @LeandroFavero!
I'll have to check it out - I think it'd be a good addition.

This has been added to the latest version of sqlpad, now available on npm :)


sync Info | in Rest API  page: 2023-09-01-preview (retiring April 2, 2024)

[Enter feedback here]
in https://learn.microsoft.com/en-us/azure/ai-services/openai/reference#completions
2023-09-01-preview (retiring April 2, 2024)
in https://learn.microsoft.com/en-us/azure/ai-services/openai/api-version-deprecation#retiring-soon
Retiring soon
On April 2, 2024 the following API preview releases will be retired and will stop accepting API requests:
2023-03-15-preview
2023-06-01-preview
2023-07-01-preview
2023-08-01-preview
Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: a2c2654a-a122-7c5d-6052-5c1e532482bb
Version Independent ID: f955b829-af26-91d3-ae33-4aa0ed26d5a2
Content: Azure OpenAI Service API version retirement - Azure AI services
Content Source: articles/ai-services/openai/api-version-deprecation.md
Service: azure-ai-openai
GitHub Login: @mrbullwinkle
Microsoft Alias: mbullwin

@adamyin0115
Thanks for bringing this to our attention.
I'm going to assign this to the document author so they can take a look at it accordingly.

#please-close