Nuget package about redis HOT 23 CLOSED

Good Idea, I'll add this to our schedule. I'll try to get it done with the next drop of the code.

from redis.

I don't think this redis project is a good fit for NuGet. WebPI, on the other hand, is. Maybe http://chocolatey.org/ as well.

from redis.

I respectfully disagree.

I don't want an installer, I want a simple mechanism for getting the latest redistributables (as part of a build process for example).

Chocolatey uses the same package format as Nuget, and already has code for installing NuGet packages. I'd rather see the Chocolately package for Redis be a small wrapper around grabbing what's on Nuget, and installing it locally. Then all bases are covered.

/cc @ferventcoder

from redis.

Whichever route you go, I'm looking forward to your first release (still waiting for it since the article from April - http://blogs.msdn.com/b/interoperability/archive/2012/04/26/here-s-to-the-first-release-from-ms-open-tech-redis-on-windows.aspx). I know the article says "released _code_," but most of us have a whole different meaning attached to the word "release" when it comes to software development.

Update: That might be a little confusing now that I read it. What I meant is, release to me is not the same as sharing your source code. At least I've never heard it described with the word release. To me, when you release a product, it means there is something compiled that I can start tinkering with. So it was kind of a let down for me and some others when I came looking for the executables and there were none.

from redis.

@Iristyle when u compile the source code, you will have bunch of executable files for redis-server, redis-cli, etc. To me, there is no logic to put those inside live NuGet feed. I would never install those into my project. You might say that NuGet package can be installed anywhere. While that's correct, live NuGet feed just doesn't seem a logic place for this project.

On the other hand, there is a RedisWatcher project which is a windows service and serves as a watchdog for the redis server. I am 90% positive that WebPI is the best place for this project to be distributed as suggested under issue #16.

from redis.

@ferventcoder that is my point. Totally agree.

@tugberkugurlu

Again, totally disagree.

• Why should everyone have to build the source themselves?
• Why should an installation procedure for the binaries be imposed?
• Have you considered the possibility of running integration tests against Redis without installing the binaries on a build server? I have, which is why I put together and use the RedisIntegration package. I just don't want to have to compile these binaries at each new version -- I want to bump a ref to the official binaries. IMHO, distributing the core Redis binaries is the responsibility of the MSOT guys.

Just because you wouldn't use what's in Nuget for your use case, doesn't mean it's not useful to others. There are plenty of packages in NuGet that are 'tool' only in nature -- Psake, Xunit Runners, etc, etc.

But I don't think this is even really worth arguing, because the effort required to write a script to publish the binaries to Nuget after a build is minimal. I just want the MSOT team to do it officially

from redis.

Yeah, I know how to write a nuget package manifest and publish :) at the same time, I still think this doesn't belong to NuGet as much as it belongs to WebPI. Sure, people will use the NuGet package if there is ever gonna be one but that doesn't mean that it's the right way.

On the other hand, it is technically impossible to distribute RedisWatcher through official NuGet.Org (I mean downloading and installing it). That's for sure and I don't think this is even really worth arguing, too.

from redis.

"A release == binaries."

Is there any argument with that statement?

from redis.

@ferventcoder I don't have any disagreement on that and don't get me wrong but isn't this issue about NuGet package :)

from redis.

@tugberkugurlu We can change the issue ;) or start a new one. :D

from redis.

Now referencing Issue #17 - #17

from redis.

@tugberkugurlu Okay, so no disagreement on binaries. I did create an issue for releasing binaries a month ago and we still have no binaries. When will you guys have binaries?

from redis.

@ferventcoder I agree but I'm not a project member. I am just a random dude who has a few requests for this project (#16) just like yours. But, apparently, the project hasn't seen a single commit since August.

from redis.

@tugberkugurlu Oh! Haha. My bad. Who's got two thumbs and needs to learn how to read? This guy.

from redis.

Interesting discussion. There are 2 key scenarios that we need to target:

1. developers that want/need access to source code: NuGet is a good solution to deploy the Redis project(s)
2. users that just need the binaries. For this scenarios WebPI is the solution I think is more appropriate. We will include signed binaries, RedisWatcher and other tools that targets more the deployment and configuration scenarios

And apologies for the delay, even though there is no apparent activity we are still working on this project. The goal is to reach a level of stability that will allow us to move to an open development model where we can just use the public repo. Right now we are still trying different things, changing our minds quite often so I wanted to avoid having too much noise in the public repo.

Comments/suggestions/ideas are always welcome

stay tuned for the next release (almost ready :))

from redis.

Here's a solution that should make everyone happy: Provide "redis-bin" and "redis-src" on Chocolatey. If you prefer pre-built binaries, use the former. If you prefer source, use the latter.

Or, consider that those who want the source wouldn't normally retrieve the source via a package manager anyway. Maintain redis source on GitHub, provide binaries on Chocolatey.

from redis.

5 months and no official NuGet package still.. yikes 😦

from redis.

Now that we have the 2.6 version out we can focus on making the overal download/install experience better. Next in our the feature listare NuGet and WebPI. We will look into adding support for Chocolatey as well. For NuGet should be able to get something out next week.

from redis.

We just published two NuGet packages for Redis 2.6.8-32 and 2.6.8-64

from redis.

@clca I tried to install it through nuget.exe by running NuGet.exe install Redis-64 but got the following error:

WARNING: Package does not contain a manifest.
WARNING: Package does not contain a manifest.
Package does not contain a manifest.

from redis.

Package does not contain a manifest.

Same error here (Redis 64bit, VS2010)

from redis.

Here is the output from NuGet.exe install Redis-64 -Verbosity detailed command:

GET http://www.myget.org/F/aspnetwebstacknightly/FindPackagesById()?id='Redis-64'
GET https://nuget.org/api/v2/FindPackagesById()?id='Redis-64'
GET http://www.myget.org/F/katana/FindPackagesById()?id='Redis-64'
GET http://www.myget.org/F/owin/FindPackagesById()?id='Redis-64'
WARNING: Package does not contain a manifest.
WARNING: Package does not contain a manifest.
GET https://nuget.org/api/v2/package/Redis-64/2.6.8.1
System.InvalidOperationException: Package does not contain a manifest.
at NuGet.OptimizedZipPackage.EnsureManifest()
at NuGet.OptimizedZipPackage..ctor(IFileSystem fileSystem, String packagePath)
at NuGet.LocalPackageRepository.OpenPackage(String path)
at NuGet.LocalPackageRepository.GetPackage(Func2 openPackage, String path) at NuGet.LocalPackageRepository.<>c__DisplayClass9.<FindPackage>b__5(String path) at System.Linq.Enumerable.WhereSelectEnumerableIterator2.MoveNext()
at System.Linq.Enumerable.WhereSelectEnumerableIterator2.MoveNext() at System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable1 source)
at NuGet.LocalPackageRepository.FindPackage(Func`2 openPackage, String packageId, SemanticVersion version)
at NuGet.LocalPackageRepository.FindPackage(String packageId, SemanticVersion version)
at NuGet.PackageRepositoryExtensions.FindPackage(IPackageRepository repository, String packageId, SemanticVersion ver
sion, IPackageConstraintProvider constraintProvider, Boolean allowPrereleaseVersions, Boolean allowUnlisted)
at NuGet.DataServicePackage.EnsurePackage(IPackageCacheRepository cacheRepository)
at NuGet.DataServicePackage.get_FrameworkAssemblies()
at NuGet.PackageExtensions.HasProjectContent(IPackage package)
at NuGet.PackageWalker.GetPackageTarget(IPackage package)
at NuGet.PackageWalker.GetPackageInfo(IPackage package)
at NuGet.PackageWalker.ProcessPackageTarget(IPackage package)
at NuGet.PackageWalker.Walk(IPackage package)
at NuGet.InstallWalker.ResolveOperations(IPackage package)
at NuGet.PackageManager.Execute(IPackage package, IPackageOperationResolver resolver)
at NuGet.PackageManager.InstallPackage(IPackage package, FrameworkName targetFramework, Boolean ignoreDependencies, B
oolean allowPrereleaseVersions)
at NuGet.PackageManager.InstallPackage(IPackage package, Boolean ignoreDependencies, Boolean allowPrereleaseVersions)

at NuGet.PackageManager.InstallPackage(String packageId, SemanticVersion version, Boolean ignoreDependencies, Boolean
allowPrereleaseVersions)
at NuGet.Commands.InstallCommand.InstallPackage(IFileSystem fileSystem, String packageId, SemanticVersion version)
at NuGet.Commands.InstallCommand.ExecuteCommand()
at NuGet.Commands.Command.Execute()
at NuGet.Program.Main(String[] args)

from redis.

Very sorry guys, my bad. I uploaded the packaged using the nuget Web site and it didn't give me any warning. I wrongly zipped the packages including the root directory.
I republished both packages and had to rev the version to 2.6.8.2

from redis.