Excerpts from Domen Kožar's message of Mon Apr 07 17:31:58 +0000 2014: > As soon as we allow more than one design pattern for sharing code between > packages, package in my use cases means "having same name and having most build instructions be the same".
We do already have "sharing" for different "systems", eg src = if system = "X" then fetchurl else fetchurl .. Eg eclipse case. > I'm OK with versionedDerivation, if we come to consensus it's better than > current approach and someone ports current codebase to use > versionedDerivation. That's not what I'm asking for: (rewriting code). The main request is: Is it worth thinking that much about such small things if such patches fix real world problems people might suffer from. I want to achieve the goals with reasonably low effort - thus do what works fastest. If we can imagine that this happens on this own - there is no reason to fear that there is a maintenance burden - because if there is one it'll be refactored (because contributors want to be done fast, too) > TL;DR: having more than one way to share code between packages Thus you'd vote for "mkDerivation" and setup.sh being the only sensible ways to share code ? :) Just trying to illustrate that its hard to define what one labels as "shared code". > burden to maintenance We should talk about specific cases, not about "general things" which are hard to grasp. Please keep in mind that you cannot prevent programmers from shooting themselves into their feet - no matter what you do. The question I'm asking is: Am I doing this is the cases I provided and for what reason - and which kind of gun am I using (soft balls or missiles). Marc Weber _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev