Please reach out to us and let us know which operations you would like to see in a first version of the API.
@Michael Ketting, try the following for removing NuGet packages:
nuget delete $PackageName $PackageVersion $ApiKey -Source https://www.myget.org/F/feedname/api/v2/package?hardDelete=true
Alternatively, you can simply submit an HTTP DELETE request to the following endpoint:
DELETE /F/feedname/api/v2/Package/$PackageName/$PackageVersion?hardDelete=true HTTP/1.1
@James please get in touch with support, we may be able to help out
It's on our radar. We're currently doing a lot of back-end changes to support building an API. No ETA yet but it's high on our list :-)
You could create multiple feeds for this, e.g. a prerelease and stable feed. The package promotion flow can then be used to move a prerelease to the stable feed.
@Asbjørn, status currently is 'not started', still. Feel free to reach out directly to discuss.
Not yet, we definitely want to add this but priority-wise there are more urgent things to tackle.
Would having access to the feed be OK or is the access control something you want at the package level?
Have you tried our new MyGet Credential Provider for Visual Studio 2017 yet? http://docs.myget.org/docs/reference/credential-provider-for-visual-studio
We are working on improving that very experience, so we’re very eager to hear your feedback on this.
Interesting. In essence, are you suggesting MyGet Enterprise administrators should have the ability to restrict token creation to certain specific users, and disable by default for any other user (including those who still need to create their account on your tenant)? Those users essentially become read-only users in that case.
We are thinking of making API keys “scoped”, so that you can create an API key that, for example, can only consome and/or push to a given feed. Would that work?
Keeping this issue open for further improvements.
In that case an Enterprise admin can take ownership of the feed. Or you can create a separate user for it and have that user own the feed instead (not linked to a person).
Currently you an assign more than one API key to a user. The Octopus Deploy server could use a user's username and a secondary API key as the password. Would that work?
We want to support this but we're a bit in doubt as to whether this should be a separate user or an existing one with different credentials.
Would you want live output, or do the colored logs we currently have suffice?
This is on our roadmap. Would this be something you’d like to see for Enterprise plan only or all plans (like Starter and Pro?)
Currently supported in MyGet Enterprise (federated identity)
Definitely on our radar, thanks for the suggestion!
This would only work within one feed. Since we have no way of knowing other package sources "out there", this is a difficult metric. If "within one feed" is good enough, this should not be too hard for us to add :-)
Do you have any specific requests you would like to see added?
Would it make sense to make this a MyGet system user instead? The reason is some users may not have permission to add packages to a feed and it would be confusing to see they actually added a package this way.
That sounds really good
An API is in the works, planned for early 2014. This would make the senario you are desribing possible. Stay tuned!