Grouping for different environments

[forki]

See http://bundler.io/v1.7/groups.html
Do we need this? How should it look like?

@agross @ilkerde

[agross]

I never had the requirement to install a different set of dependencies for dev/test/production in my .NET projects.

I'd like to hear if anyone else sees such a requirement. Then we can decide whether it's worth to implement grouping.

Alex

Alexander Groß
Tiny phone, tiny mail

On Thu, Sep 18, 2014 at 10:53 AM, Steffen Forkmann
notifications@github.com wrote:

See http://bundler.io/v1.7/groups.html
Do we need this? How should it look like?

@agross @ilkerde

Reply to this email directly or view it on GitHub:
#116

[bartelink]

I think it's bad news - stuff that's tantamount to or encourages further usage on the deployment side is not a game one should enter lightly.

The examples in the cited page are about installing databases - something that for me is debatable as a NuGet thing and there are far better ways of managing that (esp in a cross platform way considering the variety of tooling in the space and its continuing rapid evolution)

The benefit of having a clear single idempotent (no pure, but if the inputs are the same including what the feeds say the result will be the same) result from running the tool is not to be underestimated.

And hey, it's not like we don't have an uber make tool that can manage

• generating multiple outputs per environment
• running the build multiple times but switching the target environment

OTOH when I first saw the issue I though "Coool, another composable thing I can hack with: :D If the processing of Paket.dependencies had remained as an active script, one could simply provide a mechanism for arguments to paket install/update to feed in as args and let the deps file do it's worst.

But I think as long as the dependencies format stays sane, people with corner cases can simply preprocess it before passing it to paket [to achieve the overall goal and/or to do wacky things like varying the target NuGet location]

[ilkerde]

I don't think we need it. I never ever had the requirement to change dependencies depending on env/configuration. The only thing I could reason on is testing packages, such as NUnit, Mspec et al.

However, this IMHO is not a package dependency concern but a reference concern. I'm not sure if such a feature can play a vital part to support stuff like SpecsRemovement.

It's common practice is JS land to flag deps as "dev" when they are concerned with meta-construction on the project, such as test runners, task runners, build tools. Again, I'm not sure about the immediate or indirect effects of sucha feature porting to .NET ecosystem.

I don't see this feature to be on out agenda now. Let's don't overly make things complex. I recommend to ditch the feature.

[forki]

nice.

can anyone provide a good FAQ for this? I'm asked this a couple of times.