Yortw
Include Hammock as a dependency
How come you have choosen to include the Hammock.ClientProfile assembly in the package? Wouldn't it make more sense to declare it a dependency?
Hi,
The version of Hammock shipping with TweetMoaSharp has been modified from the original for the purpose of keeping TweetMoaSharp working, so I can't reference the original Hammock package. I also have no desire to keep supporting Hammock as an independent module, or to encourage it's use, therefore I have not published it as a separate package. Without a separate, up to date, package, it can't be listed as a dependency. Further, I don't own the original package and can't update it, so I'd need to invent a new name and then clarify for everyone who turned up confused using the original package.
I feel that if you're starting a new project these days you should be using HttpClient, or on older platforms I would prefer people use a library that didn't conusme my time to maintain. Therefore, no independent package for Hammock.
I have tried (once) removing Hammock from TweetMoaSharp, but it is not easy, especially if you want to keep backwards compatiblility for people using the non-async methods, and support for platforms where async/await and/or HttpClient don't exist. It's also a non trivial amount of stuff to re-implement in a nice way anyway.
Basically, I now treat Hammock as part of TweetMoaSharp, not an independent entity, even though I've kept the existing repo/solution/project structure from my initial forking. Moving all the Hammock code into TweetMoaSharp so it's in the same assembly might be a good idea, but it's work that involes time I haven't had.
You only need to ship the one Hammock assembly required for the platform(s) you support, so there shouldn't be a case where we are shipping unnecessary assemblies. For some platforms (i.e Net 3.5) Hammock targets the client profile because that will work for projects targeting either the client or full profiles. That shouldn't be causing any overhead or issues for anyone as far as I'm aware. Even if I published Hammock as separate package, those platforms will still use the client profile assembly.
Unless of course I've misunderstood the question? Possibly a dll is being included in an incorrect folder within the pacakge somehow?
I see your pickle.
But if you are including a modified version of a listed package things can get really confusing. If I install your package and afterwards install the hammock.clientprofile package this might overwrite your hammock.clientprofile assembly and practically render tweetmoasharp broken. Leaving the user confused.
If hammock is out of your control and you need a modified version of it you can include it in your package but you need to modify the assembly name and the namespaces. To make sure it can co-exist. :)
Having the same assembly in different nuget packages can also result in really wonky errors where visual studio asks for an assembly that doesn't exist. See my answer on this stackoverflow http://stackoverflow.com/questions/27976099/visual-studio-asks-me-to-reference-a-nonexistent-assembly
Excellent points! This is exactly what I would expect/ask someone to do if they forked and republished my work. I guess the difference here is that both the original TweetSharp and Hammock are dead. The original idea with TweetMoaSharp was for it to be a total drop in replacement for TweetSharp, including namespaces & assembly names so people didn't have to refactor anything or update installers. While I could update Hammock as you suggest, I should technically do the same with TweetMoaSharp and haven't. If I change them now not only do we lose the drop in replacement status, but it's arguably a worse time to make such a breaking change. Again, no question about this if the original projects were still active, but as they're dead and buggy I doubt anyone is using them so I'm not sure if it's a problem that needs solving.
What if you:
- Pull Hammock source into your repo proper
- Move all types into a namespace under your current root namespace
- Rename the output assembly to include your root namespace
So continue using Hammock, but avoid the grossness of sub-modules as well as the potential for conflicts with other things that use Hammock. Since Hammock is dead, you don't exactly need to keep it as a stand-alone repo in order to easily receive updates.
I'm not sure you can solve your own namespace problem without breaking existing consumers as you say.
Possibly the best way to go about this if someone wants to have ago. It's a reasonable amount of work for a problem that may never (and is ulikely to IMHO) occur and still doesn't solve the breaking changes issue with TweetSharp, as you pointed out.
If anyone who's reading this has a problem with the potential breaking changes, please comment.
I had the same approach in mind that Collin mentions. Simply including the code in your assembly under a different namespace. This shouldn't be a breaking change. Since you are still able to install the hammock package. (Since your version of hammock is in a new namespace)
The breaking change stuff is in reference to TweetSharp... there is an argument (tho perhaps not a good one) that if we need to change Hammock namespace/assembly name/filename to avoid conflicts that we should do the same with the main Tweet(Moa)Sharp assemblies.
If anyone wants to submit a PR cool, otherwise this can stay on the list until I have time.