[Nix-dev] Design Patterns for Achieving what Nix is Advertized for

[Jonn Mostovoy]

> which is too complex to describe in this small contemplation.
“I have discovered a truly remarkable proof which this margin is too
small to contain.”

Regarding first workaround:
You are right, package names won't collide, however package purposes
will and files created on the file system will.

Regarding second workaround:
Indeed, this way, computer doesn't need to solve dependency
constraints. A human has to. For every single package.
Please let me remind you that we need package managers for humans to
work less, not more. Maintainers are humans too.
—
Kindest regards,
¬Σ


On Fri, Nov 27, 2015 at 3:09 AM, Martin Vahi <martin.vahi at softf1.com> wrote:
>
> In the light of the instability of the Nix
>
> https://github.com/NixOS/nix/issues/718
>
> I started to think, if it is possible to achieve
> the same goals without using the Nix. Could someone
> please comment, if there is something that
> the Nix offers and the solutions described
> here by me do not offer? Comments on flaws
> within the described desing patterns are also welcome.
>
> Nix sales argument:
>     Multiple versions of the package can
>     be used simultaniously and each of the
>     packages can use its own set of dependencies.
>
> Proposed workaround design pattern:
>     Each version of the package is published
>     to a traditional Debian/RedHat packaging
>     system under its own name, id est the
>     version of the package is part of the
>     package name. There exists a specially
>     named package that always references
>     to the newest version, something
>     along the lines like
>
>         gcc_newest
>
>    Different versions would be:
>
>         gcc_v_4_9_CPUFAMILY_x86_CPUSUBTYPE_i386_SOFTWARECONFIG_1
>         gcc_v_4_9_CPUFAMILY_x86_CPUSUBTYPE_i386_SOFTWARECONFIG_2
>         gcc_v_4_9_CPUFAMILY_x86_CPUSUBTYPE_i486
>         gcc_v_4_9_CPUFAMILY_x86_CPUSUBTYPE_i586
>         gcc_v_4_9_CPUFAMILY_x86_CPUSUBTYPE_i686
>         gcc_v_4_9_CPUFAMILY_arm
>         gcc_v_4_9_CPUFAMILY_AMD64_SOFTWARECONFIG_1
>         gcc_v_4_9_CPUFAMILY_AMD64_SOFTWARECONFIG_2
>         gcc_v_4_9_CPUFAMILY_MIPS
>
>         gcc_v_4_8_CPUFAMILY_arm_v6
>         gcc_v_4_8_CPUFAMILY_arm_v7
>         gcc_v_4_8_CPUFAMILY_x86_SOFTWARECONFIG_1
>         gcc_v_4_8_CPUFAMILY_x86_SOFTWARECONFIG_2
>         gcc_v_4_8_CPUFAMILY_x86_SOFTWARECONFIG_3
>
>    The package names would actually conform to a
>    small domain specific language(DSL) with its own
>    syntax and semantics, which is too complex
>    to describe in this small contemplation.
>    The DSL would require that packages with
>    different names do not collide by their
>    package name meaning. Id est only one of the
>    following 2 names would be allowed:
>
>        gcc_v_4_8_CPUFAMILY_x86_SOFTWARECONFIG_1
>        gcc_v_4_8_SOFTWARECONFIG_1_CPUFAMILY_x86
>
>    (The implementation might be simplified so that
>    the package names are generated by a
>    helper Ruby script, where people just "fill in forms".
>    The Ruby script acts as a primitive "formal verifier"
>    for the DSL.)
>
>
> A remark:
>     As of 2015_11_27 it seems to me
>     that that kind of design pattern
>     has been already widely implemented.
>     Not with so much detail, but that's a
>     matter of rigor at the part of the
>     package maintainers, not that the
>     Debian/RedHat packaging system would
>     limit the use of that design pattern.
>
>     If everything were packaged with such rigor,
>     then very specific dependencies could be
>     declared for every package. What regards
>     to the idea that it might be laborious to
>     create a separate package for every CPUFAMILY
>     CPUSUBTYPE, then like it or not, as it turns out
>
>     https://github.com/NixOS/nix/issues/84
>     https://github.com/NixOS/nixos/issues/66
>
>
>     in practice, that's a job that has to be
>     done anyway, specially at the testing side.
>     The naming scheme just shows the vastness of
>     the actual task.
>
>
>
> Nix sales argument:
>     It is possible to select, what packages
>     are available in the environment(PATH, libs), the
>     environment is versioned(allowing rollbacks, branches, etc.)
>     and the environments are reproducible on
>     different computers by having the clone computer
>     go from state 0 (the "hello" has been installed)
>     to the destination environment state by
>     going through all those state tree vertices
>     that are on the path from the root (the "hello")
>     to the leaf or some vertex in between.
>
>
> Proposed workaround design pattern:
>     Package all software so that the
>
>         <package folklore name like the gcc>_newest
>
>     is never referenced at any build script.
>     In that situation the walking of the state tree
>     looses its point, because the task of achieving
>     a state reduces to satisfying the dependencies
>     of the state. Dependency graph regions that do not depend
>     on each other and have their common dependencies
>     met, can be built/compiled in parallel,
>     at different operating system processes, may be
>     even on different computers.
>
>
> So, thank You for reading this long letter and
> the question is, what am I missing, where am I mistaken?
>
>
> Curiously and from a position of a heretic,
> Martin.Vahi at softf1.com
>
>
>
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>