[HN Gopher] I use Nix and make(1) to develop
___________________________________________________________________
I use Nix and make(1) to develop
Author : todsacerdoti
Score : 75 points
Date : 2023-04-24 15:31 UTC (7 hours ago)
(HTM) web link (glorifiedgluer.com)
(TXT) w3m dump (glorifiedgluer.com)
| haolez wrote:
| Make is one of the best tools I've ever come across, but with one
| big caveat that none of your files must have spaces on their
| names or all hell breaks loose. Seems like a reasonable trade off
| to me :)
| zelphirkalt wrote:
| Is this an issue of make, or shell? If we properly quote all
| variable usage, shouldn't it simply result in quoted values in
| shell commands, which are then correctly interpreted? Or do you
| mean when using something with spaces in make in-built
| functions?
| haolez wrote:
| It's a make limitation when using its native functions. It's
| very hard to work around this.
| bee_rider wrote:
| Files with spaces in the name are just a bad idea anyhow, Make
| is just helping out by making the problem more explicit.
| pmarreck wrote:
| > Files with spaces in the name are just a bad idea anyhow
|
| It's only a bad idea because of assumptions programmers make
| about file paths not containing spaces that they then build
| into their code and cause problems.
|
| The Mac (and user-friendly file names that contain things
| like spaces) has been around since 1984. Why has it taken
| this long to just accept that file paths might contain
| spaces? Is it just because (essentially) Bash is a huge pain
| about quoting?
| bee_rider wrote:
| Regardless of why or how good it is, people are going to
| keep making this assumption. Is it really a worthwhile hill
| to die on?
| pmarreck wrote:
| The only thing keeping people making this assumption is
| inertia and the only way to change inertia is by leaning
| into it. I like documents named "Paper about
| Nietzsche.doc", not "Paper_about_Nietzsche.doc" and
| directories named "Party Photos" over "Party-Photos" etc.
|
| It's about the user aesthetics, not the ease of the
| coder.
| rgoulter wrote:
| IIRC, "spaces in file paths breaks programs" is explicitly
| why Windows uses "Program Files" as its default installation
| path; so that programs would be written with robustness to
| that.
| mauvehaus wrote:
| All the world does not speak English:
|
| https://www.samlogic.net/articles/program-files-folder-
| diffe...
| enriquto wrote:
| > Files with spaces in the name are just a bad idea
|
| Hear, hear! I would love a mount option that disallows them
| for good (or replaces them transparently by nbsp U+00A0).
|
| Do people also want variable names with spaces in their
| programs? Filenames _are_ variable names, and the file
| contents are the data that the variable refers to. Allowing
| spaces in variable names is just brain damage.
| lnxg33k1 wrote:
| I have also been using make for the past few years, and since
| then whenever I jump on a new project, right away I get the
| readme and commands needed to do stuff with a project, and put
| them in a Makefile, and people start loving me right away. It's
| baffling to me how easy but ignored is make and how people accept
| to write / remember un-mnemonick commands without looking for
| alternatives/solutions
| thechao wrote:
| For C(++), I use make and ccache. I can just use `find` to
| place a naive dependency of every header file on every C file;
| and, `*.d` files (from clang/gcc): I get nearly perfect
| incremental builds, without file updates breaking the build, in
| parallel. Totally bulletproof and works on all the Unixen I
| care about (Linux, macOS, BSD).
| lnxg33k1 wrote:
| I see what you say, and also understand the amount of time /
| boredness you save with this simple setup, that between us,
| is simple simple no? But you go around and people maybe stay
| at the PC waiting for compilation forever and accept to wait
| forever, despite that being one search/doc read away.. it's
| really baffling.. and keeps me thinking now maybe it's that
| the reason why people consider linux/bsd hard non-user
| friendly systems, because it's either you throw the solution
| at them, or they would just ignore how simple is something
| and how would change their productivity / workflow by orders
| of magnitude
|
| I had a makefile a while ago that would incrementally build
| docker containers based on containers metadata (for the
| dockerfile content hash) and would update those changed
| automatically, and it took like 2 minutes, instead of
| complaining while waiting, it's crazy how much simplicity is
| just ignored
| aemonfly wrote:
| very interesting, any more details?
| throwaway290 wrote:
| Careful-- there only thing worse than no makefile is
| unmaintained and outdated makefile full of dark magic and
| obscure shorthands.
| lnxg33k1 wrote:
| Yeah but it's like a good reasoning valid for just about
| everything, like code that is undocumented or abandoned
| because people have left is just as bad, but that doesn't
| make us stop writing applications? Everything is good or bad
| depending on developer's attitude.. I don't really feel your
| point specific for Makefile or as discouraging about
| Makefiles..?
| throwaway290 wrote:
| It does (or should) make us write less code if possible;)
|
| Not arguing makefile has value but I worked on legacy
| projects with makefiles that break in mysterious ways and
| in those cases I would take the same stuff with hows and
| whys spelled out in plain English instead!
| bee_rider wrote:
| The only thing I don't like about make, is it feels like having a
| configure and make file sets the expectation that:
|
| ./configure
|
| make all
|
| Will actually have a good chance of working, which is not
| something my makefiles can live up to!
| thomastjeffery wrote:
| I can't tell if you meant to imply this, but that is the very
| benefit Nix provides: a guaranteed stable _and_ sterile
| environment where . /configure, make all, and make install can
| be run. No more chances.
| hawski wrote:
| If you have a configure step it can fail by default if there is
| anything to specify explicitly. But otherwise it is nice to
| have some defaults. In my opinion a configure script shouldn't
| do much in terms of detection. It should not silently
| enable/disable features based only on libraries being
| present/missing. By default it should try to use lib a and b,
| if the user wants they could explicitly opt-in to use lib c
| without lib b, otherwise let it fail.
|
| That said it all makes it easier to just use config for make
| that can be edited. For example config.mk included by Makefile.
| I learned this trick from Suckless.
| rgoulter wrote:
| Using `make` with `.PHONY` targets is what I'd call a "task
| runner". -- In NodeJS, a package.json's "scripts" serve a similar
| task.
|
| I think the main/only reason to go out of your way to use `make`
| as a task runner is its ubiquity.
|
| However, if you're already using nix, it's probably not much of
| an issue to use a better task runner.
|
| I'd recommend 'just' instead https://github.com/casey/just -- It
| has a nicer UX, with a few significant quality-of-life
| improvements out-of-the-box compared to `make`. e.g.
|
| - you can get a list of tasks, and select one using `fzf` with
| `just --choose`.
|
| - can inline use of bash, or python, etc.
|
| - `just` automatically searches up a directory tree for a
| `justfile`.
| yjftsjthsd-h wrote:
| > I think the main/only reason to go out of your way to use
| `make` as a task runner is its ubiquity.
|
| In fairness, that's a pretty big reason.
| rgoulter wrote:
| For projects where you need to collaborate with others, yeah.
|
| For personal projects like "how I generate my static site",
| and where you're already using a tool like nix, 'tool already
| installed' isn't worth going out of your way for.
| wdroz wrote:
| I switched to Just for most of my projects. The only thing I
| miss from Make is the possibility to run the tasks in parallel.
| zelphirkalt wrote:
| NPM has no concept of dependencies of steps like make has for
| what people use in "scripts". It is painful to see people doing
| that all the time and then constructing their commands as long
| strings, which the tool they use has no knowledge about, using
| recursive invocation and having to write "npm run" again and
| again in those long strings, while in a Makefile it is all
| figured out automatically, as dependencies of steps are clearly
| stated as such.
|
| It feels akin to handling HTML as a long string and fumbling
| around in it, as was done in the past in many PHP projects,
| instead of handling HTML as structured data, an XML tree or
| similar.
|
| NPM package.json scripts is a Makefile for the very poor. Yes
| it can be used like that. Should it? When commands start to
| have prerequisites probably not.
| zelphirkalt wrote:
| I use make and GNU Guix. Quite similar. You take make as a task
| runner and a dependency manager/package manager as a means to
| construct a reproducible setup for a project.
| LanternLight83 wrote:
| Sometimes I bake Nix into my personal Makefiles.
|
| This means that we lose the non-Nix build processes, but _I_ get
| to keep the best of both worlds, and don 't have to run `nix
| shell` or setup direnv.
|
| "Uhm, actually" I use Guix, but the idea is the same:
| SHELL = guix shell -m manifest.scm -- bash public: hugo
| content emacs $(pwd) --batch -l export.el [...]
|
| Or without an external manifest: SHELL = guix
| shell --pure bash coreutils emacs emacs-ox-hugo hugo -- bash
|
| This is equivalent to the common shebang trick:
| #!/use/bin/env -S guix shell -m manifest.scm -- bash
|
| Or just invoking Guix inside the recipe: public:
| hugo content guix shell -m manifest.scm -- emacs $(pwd)
| --batch -l export.el
|
| Depending on the complexity of `export.el` (< 5 lines?), I'll
| often keep that inside the Makefile too; the less files, the
| better!
|
| But I get it if one wants that file available to call from
| elsewhere.
| thomastjeffery wrote:
| > "Uhm, actually" I use Guix...
|
| And there you have it: the fundamental problem. What if I want
| to port your package to Nix?
|
| In practice, I'm sure it's doable, but you are introducing a
| lot of overhead and complexity by putting that work into that
| place.
| ChadyWady wrote:
| Definitely agree that Make and Nix is a nice combination,
| especially for facilitating faster development like the `hugo
| serve` use case.
|
| I'd also argue it makes your code overall less volatile. If you
| ever wanted to build your code outside of Nix for whatever reason
| (such as migrating to another reproducible packaging tool),
| having everything in unopinionated `make` is a whole lot easier.
| Plus, it leverages the advantages of a tool that is dedicated to
| building code.
| MuffinFlavored wrote:
| [flagged]
| ElevenLathe wrote:
| Maybe Nix is pretty niche (though getting bigger -- I've heard
| several "hey this seems like something we should look at" type
| conversation about it at my very technically conservative
| company) but emacs is very, very old (predating Linux even) and
| definitely not "trendy." If anything, the perception on the
| mailing lists is that emacs is on the way out unless a new
| generation of users/maintainers can be recruited.
| MuffinFlavored wrote:
| > the perception on the mailing lists
|
| How many people in 2023 browse/dedicate time to mailing
| lists?
|
| I'm not trying to pick on anybody or make fun of anybody and
| say "oh my gosh you have too much free time on your hand". I
| don't really know what I'm trying to say. It's just
| interesting to me.
|
| The author did a very nice thing sharing their experience
| with the world for others to benefit and I am grateful. I am
| just zooming out a bit more macro and saying "who outside of
| the software community would understand dedicating hours to a
| blog article that may or may not help others on ________"
| where ______ is relatively fringe technologies.
|
| What does this blog article offer that Nix
| documentation/examples doesn't?
| [deleted]
| viraptor wrote:
| > Where do they find the time to play like this?
|
| Those are hobbies. It's healthy to have them. Some people like
| to run, some play musical instruments, some poke around non-
| mainstream software.
| MuffinFlavored wrote:
| [flagged]
| GrinningFool wrote:
| > How "good" of an investment of time is it to have
| "unhealthy hobbies"?
|
| Why would you (personally) try to assign your values to
| someone else's hobbies? Is this your own hobby?
|
| > How many people outside of the software community would
| understand/relate to this type of hobby?
|
| I don't understand the relevance of this, and am now trying
| to figure out now if all responders on this thread have
| been successfully trolled...
| viraptor wrote:
| A hobby's not a job. It doesn't have to be a good time
| investment, or healthy, or relatable, or ... If it makes
| you happy when you do it, that's good enough.
|
| I wrote that's is healthy to have them, not that they need
| to be healthy activities. If you only do things where
| you're interested in investing your time, or improving
| something, that's a possible path to burn out. It's nice to
| do useless stuff with no expectations too.
| MuffinFlavored wrote:
| [flagged]
| [deleted]
| viraptor wrote:
| > aren't where they should be in their careers
|
| Why _should_ they be at a specific place? Maybe their
| life goals are different than yours? Are they enjoying
| their current lives?
|
| > How far off is writing a blog article about Nix + make?
|
| Likely a bit further away in terms of creativity / time
| commitment. But I'm not going to judge either. Let people
| enjoy things we don't like/get :-)
| blipvert wrote:
| NEWSFLASH: Having more than one hobby is possible!
|
| Film at 11.
| burnished wrote:
| Sounds like you are just being grumpy.
| striking wrote:
| Hi, I use Nix and Emacs at work. I have, at points in the past,
| promised to write a blog post about how we use Nix.
|
| It's not about being hip or fringe. Nix solves problems we
| have. And we're not the only ones. The founder of Hashicorp
| puts it this way:
|
| > I'm actively trying to work through my Nix God complex. It's
| been so long that when I see non-Nix users complain about
| issues getting software to run, I'm truly confused. It's like
| someone looking at a river lamenting about having to ford it
| while I'm riding a bicycle on a bridge
|
| (https://twitter.com/mitchellh/status/1650201460234412032)
|
| Nix isn't ready to be mainstream yet. That doesn't mean you
| should talk down to those who are working towards that today.
| It is entirely possible that you may end up working with it
| yourself in due time.
| aewens wrote:
| Skimming over the contents of the "About" page linked in the
| navigation at the top of the blog, it looks to answer most of
| your questions ;)
|
| https://glorifiedgluer.com/about
|
| The OP appears to be student and software engineer that is
| employed writing F# and Nix, and made the blog purely as an
| outlet to document the things they are interested in (and good
| on them that).
| 1MachineElf wrote:
| >How "fringe" can I be. How niche of technologies can I use.
| How deep down a rabbit hole can I go avoiding mainstream
| "technologies".
|
| As a Nix user, I'd say this is the wrong characterization. It's
| not about being niche, bikeshedding, or yak shaving. It's just
| about getting as close as possible to perfection.
| Joker_vD wrote:
| > It's not about being niche, bikeshedding, or yak shaving.
| It's just about getting as close as possible to perfection.
|
| Did you mean to write "getting as close as _reasonably_
| possible to perfection "? Because getting as close as
| possible to perfection absolutely does involve bikeshedding
| and yak-shaving; that's why the saying "perfect is the enemy
| of good" exists and why people are generally advised to avoid
| gold-plating.
| umanwizard wrote:
| You just wrote a multi-paragraph post about how someone's hobby
| is a waste of time, which is ironic, because surely writing
| that post was just as much a waste of _your_ time.
| MuffinFlavored wrote:
| [flagged]
| [deleted]
| xapata wrote:
| Isn't that true for just about every activity? On a
| tangent, would you like to hear about my carbon steel
| skillets?
| tikhonj wrote:
| Why would it take any more time than learning and dealing
| with "mainstream" technologies? I've wasted _far_ more time
| on Docker proportional to the use I 've gotten out of it
| compared to Nix or Emacs!
| namaria wrote:
| You're not calling out anyone. You're calling someone's
| else work a waste of time because you don't like it. That's
| just rude.
| taylodl wrote:
| I'm not sure I see your point. Nix is cross-platform, emacs is
| cross-platform, and make is cross-platform. With the exception
| of Nix, make and emacs have been in use by many, many shops for
| _decades._ It just doesn 't get talked about much because
| they're long past being considered fun and sexy.
| whateveracct wrote:
| I've used Nix at my last 5 jobs. It's how I learned it (mostly
| as a build tool and package manager). I also started to use
| NixOS for my desktops after using NixOS for server config at a
| few of those companies.
|
| emacs isn't hipster imo. Maybe some people treat it as such?
| But I learned it in university when I was learning to code in C
| and Scheme and never looked back. It's always been the boring
| choice.
|
| I'd say they are very practical choices for a specific type of
| person who likes principled software and hacking.
|
| I don't blog about either of them though :)
| plaguepilled wrote:
| Nix is not a "required skill" by any means, but it fixes a very
| annoying problem that you may-or-may-not face related to
| dependency conflicts. NixOS also has atomic updates.
|
| I think calling it hipster is a bit odd. Its not like I would
| say Java is a bad tool because I don't use it for embedded
| stuff. Java is fantastic for enterprise and even start up
| contexts.
|
| Similar arguments can be made with emacs. Its a text editor,
| and you can do a bunch if stuff with it. Vim is also good.
| Jetbrains is also good. There's a bunch of other good ones. It
| probably depends on what you're doing. It'd be a more
| meaningful discussion if you defined a problem space.
|
| I probably would have ignored your post of it wasn't for the
| TikTok comment. Nix useage is sort of thoughtful-by-design,
| which is antithetical to TikTok use. Rubbed me the wrong way.
| [deleted]
| mikrl wrote:
| >Where do they find the time to play like this?
|
| For me it started in university when I had more unstructured
| time and continued post graduation because I found it more
| interesting than most TV, video games etc.
|
| Feels surreal to see "normies REEEE" type sentiment applied to
| old-software hackers on a hacker forum :P
| ivan888 wrote:
| I'm very new to make(1), but became a fan quickly.
|
| Rather than maintaining documentation that inevitably gets out of
| date, if a project has a Makefile, it self documents the build
| process, language independently. No need to read a README to see
| if people are currently using yarn or npm, or find external
| documentation on a build tool you haven't used before; the
| Makefile shows the targets and what commands they run.
| rochak wrote:
| Obviously you haven't seen > 100 line makefiles. They are a
| mess to understand and I have no interest in wasting my time to
| understand what they are doing.
| JohnFen wrote:
| In most of my professional work, a 100 line makefile would be
| considered a short makefile!
|
| They're not that hard to understand and follow.
| chrismarlow9 wrote:
| Just my opinion but make is still the best ci/cd tool. I see
| way too many places with layers of tools and yaml configs and
| hosted cvs pipelines (that you can't easily recreate locally),
| when a make file would do just fine if not better.
| hawski wrote:
| I recently started eyeing ninja and for many cases it makes
| more sense than make.
|
| Still those ci/cd configs should always be very thin wrappers
| (single command for single thing) around whatever script
| tooling is used internally.
| kristjansson wrote:
| It's very, very convenient to have your CI/CD yaml just
| trigger make targets. Still get the benefits of everything
| running on Someone Else's Computer, but mostly-to-100%
| reproducible locally for debugging.
| pgeorgi wrote:
| A hard learned lesson we had over at coreboot. Now all the
| projects we run CI for are heading towards some variant of
| `make what-jenkins-does` as in https://review.coreboot.org/
| plugins/gitiles/coreboot/+/refs/...
| chrismarlow9 wrote:
| This is the route I take in my personal projects. Jenkins
| runs a make file.
| miroljub wrote:
| Here you assume that more people know about make than npm or
| yarn, which I wouldn't bet on.
|
| Besides, I would guess that every JavaScript developer when
| jumping on the new project will know how to use npm, just like
| every Java developer would know enough maven, and adding some
| supposedly general standard tool on top of already standard
| tools in that area wouldn't help.
| Hendrikto wrote:
| > just like every Java developer would know enough maven
|
| Many only know Gradle.
| miroljub wrote:
| > Many only know Gradle.
|
| True, but maybe 1% knows make. And since many of them run
| Windows, many don't even know how to install the correct
| version of make on their development box.
| saghm wrote:
| The tradeoff isn't just about documentation, but complexity. A
| tedious, manual build process is still tedious and manual if
| it's self-documenting, but a more streamlined build process
| without as much documentation might still be less of a burden
| overall. It's also not like Make doesn't have its own thorny
| edges too; one person's self-documenting use of a feature is
| another person's inscrutable magic invocation. If you're
| working on a team project and already require a certain level
| of expertise in the ecosystem you're using, it's arguable that
| using the native build system (warts and all) will be a better
| tradeoff.
| pharmakom wrote:
| Reading this I felt that instead of "nix develop -c" we could use
| "docker run".
|
| Has anyone compared these two approaches?
| pmarreck wrote:
| What smilliken said. Essentially, with a single flake.lock
| file, you get build determinism, which is huge. Docker cannot
| guarantee that... which is, in fact, why distributing Docker
| images is a thing, instead of just distributing and composing
| Dockerfiles.
|
| If Dockerfiles were guaranteed to succeed, and Docker hosted a
| cache of hashed binaries instead of a cache of Docker images
| (the former is far more efficient than the latter, btw), then
| all you'd need are Dockerfiles.
|
| Enter Nix (and its flake.nix/flake.lock files).
|
| Nix essentially solves a problem that Docker can't by treating
| a build as an immutable function with binary-hashed inputs and
| binary-hashed dependencies and completely controlled
| environment variables (with a few exceptions and special cases)
| peterbecich wrote:
| On Mac where Docker runs in a VM, "nix develop -c" I think
| would be faster.
| smilliken wrote:
| Once you build a docker image, you can distribute that artifact
| reliably. But building docker images is highly error prone, at
| the mercy of non-determinism, various failure modes of package
| managers, and mutable state from web servers you don't control.
| In practice, you can't depend on it working without active
| maintenance and disciplined usage.
|
| With Nix, if it built once, it will build again, consistently
| and deterministically. It reduces fear of changing things
| because it just works. You don't have to cross your fingers and
| hope the build succeeds this time.
| pharmakom wrote:
| Doesn't seem to be an issue if you only use prebuilt Docker
| images though?
___________________________________________________________________
(page generated 2023-04-24 23:02 UTC)