Getting only needed resources on nuget install #59

Closed
MehdiK opened this Issue Jan 14, 2014 · 22 comments

Projects

None yet

6 participants

@MehdiK
Collaborator
MehdiK commented Jan 14, 2014

@hmemcpy raised a valid concern:

how can I prevent from copying all the language-specific resource to the output dir with Humanizer? Don't want 'em :)

NuGet supports two localization approach: single & satellite localized packages. Humanizer currently uses single localized package & I don't think it's possible to achieve this in this mode.

I think it's a good idea to switch to satellite packages even though it's a breaking change for this and other benefits.

To Do:

  • Create a nupsec for each locale, currently 39
  • Create script to update versions correctly on resource packages
  • Create script to push all packages to NuGet from the MyGet feed
@MehdiK MehdiK added this to the V2 milestone Apr 19, 2014
@DanAtkinson

Is this related to the large number of potentially unnecessary resource.dll files being added by Humanizer? It's made my bin directory a bit of a mess and clients are asking why so many separate DLLs are needed?
http://i.imgur.com/La7CZwN.png

@MehdiK
Collaborator
MehdiK commented Jun 17, 2014

Correct. This is going to be a breaking change to implement; so we're leaving it for V2. In the meantime, the only way to get a clean output folder is to delete the resources after build.

@jeremysimmons
Contributor

For what it's worth, I'd like to see the languages separated as separate localization packages too.
Does anyone have a workaround in the meantime?

@jeremysimmons
Contributor

A workaround for this issue is to add the following to your pre-build event.

<PreBuildEvent>forfiles /P &quot;$(SolutionDir)packages\Humanizer.1.36.0\lib\portable-win+net40+sl50+wp8+wpa81+MonoAndroid10+MonoTouch10+Xamarin.iOS10&quot; /c &quot;cmd /c if @isdir==TRUE rmdir /s/q @file&quot; &amp;&amp; EXIT /B 0</PreBuildEvent>

The encoded characters are correct. Double Quote and Ampersand have to be XML Escaped inside of the

@onovotny onovotny self-assigned this Oct 24, 2015
@onovotny
Member

Question for everyone asking to split this out -- what's really driving this? I just checked and the localization files are about 325 KB...overall, not huge.

The benefit of the current approach is that "it just works" for all downstream consumers. If you create a library that uses Humanizer, which language dependencies would you choose? Do you force that choice on your consumers who might not know that there are localization packages available?

I guess I'm partially trying to understand what the concern or care is about, what's driving it?

@jeremysimmons
Contributor

We're a corporate software shop. We cater to US clients that speak ubiquitiusly english. My build engineers freak out whenever a new DLL shows up in the BIN directory for the asp.net app, much less 38 new folders. These folders aren't needed, at all for our scenario which caters exclusively to english, which is already the assembly neutral language. [assembly: NeutralResourcesLanguage("en")]

While you're right, the overall size of files is 325 KB, the number of extra files/folders is excessive.
When we want a utility library like this we want one file.

@onovotny
Member

Okay, so I'm thinking that the NuGet localization strategy would work. MyGet may have support for this already too.

I don't think it'll make the cut for 2.0 beta 1 but hopefully should be fairly soon after.

@onovotny
Member

So here's a question re the structure. I was going to have a "meta-package" that includes all of the locales for convenience. This would be essentially v1 behavior.

The question is which should be the "default"? I.e., should the Humanizer be slimmed down to not pull in the locales by default? This is a change from v1.

The alternative is that Humanizer becomes the meta-package that pulls in everything, retaining its v1 behavior. The main contents of Humanizer goes into a new package called Humanizer.Core making the locale packages Humanizer.Core.<locale>. For people that just want English, you'd just pull in Humanizer.Core. For people that want a specific lang, you'd pull the right core locale, like Humanizer.Core.ar and it'll pull in Humanizer.Core for you.

Thoughts? FWIW, I'm leaning towards the non-breaking change, making Humanizer a meta package and moving the implementation into the Humanizer.Core package.

@mexx
Collaborator
mexx commented Oct 30, 2015

Non-breaking change sounds good. GFI

@jeremysimmons
Contributor

Is there a non Core sub-library of humanizer? Why add the name core?
I'd suggestion retaining Humanizer and adding a new package Humanizer.Localized

Another option would be to add a targets file to the distribution that would support keeping the satellite resource directories you want to include, and deleting the ones you dont.

That would allow you to always have a single package, and allow users to customize which localiztion packages they want...

@onovotny
Member

So NuGet has very specific naming conventions for doing "the right thing" with packages containing just satellite assemblies. They have to be in the form <package>.<locale>. What that means is that there will be 39 locale packages for Humanizer as there are a lot of supported languages. If we're going to split out languages, then it stands that some people may only want some languages and not all. You can pick-and-choose which languages you want.

That said, if you want them all, you can also take the main package which is a meta-package now. The idea of a meta-package is that it contains no files itself but just pulls in other packages.

In this way, we can have the following split (and the naming is just for the packages, nothing has changed in the library itself):

Humanizer: Meta-package that pulls in all 39 language packages (like Humanizer.Core.ar). Each language package pulls in Humanizer.Core as is required by the NuGet conventions. Note, that there won't be 39 copies of humanizer, it all gets normalized. This package is the "give me everything" package and is essentially the current behavior of today's package. You get the package, you get all locales.

Humanizer.Core: Just the humanizer library, symbols and help xml file. This implicitly contains the neutral language (English). If you don't want any other languages, just install this one.

Humanizer.Core.<lang>: The localized resource packages. If you want to choose which languages you need, you can install these directly. Good if you want say German and French. Each of these will pull in the Humanizer.Core package for the implementation and add the chosen language resources.

Make sense?

@jeremysimmons
Contributor

@onovotny thank you for the fantastic explanation. I agree that this sounds like a viable solution and meets my needs.

Where did you read about this convention? http://docs.nuget.org/create/creating-localized-packages doesn't describe what you just specified.

@onovotny
Member

@jeremysimmons: it's in that link under the "Satellite Package Approach". For the purposes of the convention, Humanizer.Core would be the package name. Humanizer turns into a "convenience" package that pulls the others in.

@jeremysimmons
Contributor

@onovotny Unless I am missing it, Satellite Package Approach doesn't specify the naming convention that includes the RootPackage.Core and RootPackage naming contention

@onovotny
Member

No, you're correct. That RootPackage has nothing to do with localization. That's an extra for convenience. Another way to look at it is that what is today the Humanizer package is being renamed to Humanizer.Core and adding a new Humanizer package in its place. That new package also helps preserve compatibility by preserving existing behavior for people that use the package today.

@jeremysimmons
Contributor

@onovotny the naming convention was the only point I was questioning, and simply from a learning perspective to understand where the community had documented that convention. Are there other packages that use this convention that you're aware of?

@onovotny
Member

I'm honestly not sure. It's hard to search for meta packages to see how they're named. I can say that Rx uses Rx-Main, for example, to pull in five other packages. Microsoft.OData.Core exists and pulls In a couple others. Micrososoft.OData.Client pulls in Core and adds to it.

My hope was that by keeping the main Humanizer "as-is", that it'd minimize disruption. These docs definitely need updating to describe the packages before release.

@onovotny
Member

Update 1 for VS 2015 contains the fixes for UWP support for the localized packages. This has been merged and pushed to the CI MyGet feed:

https://www.myget.org/F/humanizer/api/v2
https://www.myget.org/F/humanizer/api/v3/index.json

The Humanizer 2.0.0-dev0057 package retains current behavior (pulling in all locale packages). If you just want English, use Humanizer.Core 2.0.0-dev0057 instead. If you want one or more languages, use those directly: Humanizer.Core.he 2.0.0-dev0057, etc.

The main Humanizer package does pull in a lot of packages into packages.config. If this is a concern, I'd recommend changing over to the project.json format instead. That can be used instead of packages.config for all project types in VS 2015+. The main advantage is that only direct dependencies are listed and transitive dependencies are silently pulled in. It's far easier.

@onovotny
Member

Closing this thread out but please open new issue threads if you discover issues when testing the new packages. Thanks!

@onovotny onovotny closed this Nov 30, 2015
@jeremysimmons
Contributor

hard to contain the joy. THANK YOU!

@i3arnon
Contributor
i3arnon commented Dec 1, 2015

@onovotny Are the individual Humanizer.Core packages going to be published on nuget.org? Or is there some other way I'm missing to get them?

@jeremysimmons
Contributor

@i3arnon I imagine they will publish to Nuget when it's a stable package. Currently they are pre-release. Add the myget.org feed to your nuget feeds, and then you should be able to search for the package. This documentation on the official nuget package manager extension for visual studio may help you https://docs.nuget.org/create/hosting-your-own-nuget-feeds#creating-remote-feeds

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