Following up on my Python build woes last week, I finally got it sort of working.
In the end it was trying to use libraries that were in both `/usr/local/lib` (for `libpython`) and `/usr/local/lib64` (for `libssl` and `libcrypto`), but my existing configuration for the Python build was only looking in `/usr/local/lib`.
Next step is to figure out why Python isn't building/installing to `/usr/local/lib64`.
Have to say though - Docker really makes this kind of thing a lot easier than it used to be. Trying this in the past used to be way harder - when the environment is contaminated with leftovers from previous failed attempts, it can be hard to determine if your process will actually work in a clean system.
Today in "Shouldn't we be past this shite": trying to compile Python to use a non-system version of OpenSSL.
* Can get Python to compile and work, but it pulls in the system OpenSSL.
* Can get Python to compile, link against the non-system OpenSSL, but can't find libpython.
* Can get Python to compile, link against libpython, but is unable to find libssl/libcrypto
I’ve been working in the software industry in Belfast for over 17 years, and I’ve been to a lot of university careers fairs in that time. I got to attend more at UUJ and QUB over the last couple of days and it got me really enthusiastic about the future of software engineering in Belfast. As a hiring manager, there were so many people that I wanted to take on straight away, and can’t wait to talk to them all in the upcoming interviews.
That said, I definitely find it harder to get moving with VS Code. Some of it is overcoming muscle memory, but some of it is a clunkiness that I thought they’d have sorted out by now. The extension installation UI is abysmal for a start, and opening a new window results in a soup of stuff on the screen that doesn’t feel conducive to getting started.
Much of yesterday was spent bashing my head against #python not being able to find it's packages when invoked as a subprocess from another Python process. Every time it was run it would report an `ImportError` for the module `site`. We even set up the `PYTHONHOME` and `PYTHONPATH` through the env with no luck. Today we're hoping that using a `venv` gives us more luck.
That said, I reckon that the problem is that we rely on too many abstractions for this whole thing. NPM, Brunch, Elm, Phoenix and so on. It all adds up to me not knowing what exactly is being done on my behalf.
I suspect there's a bit of spelunking in my future to figure out how the plumbing is actually hanging together. Then maybe I'll appreciate what is broken.
I know I’m in a minority these days but I really just want new Macs. (And I don’t mean the iPhone Xs Max) The #Apple events are definitely a lot more filler than killer now.
Where are my manners - the book is for sale at https://pragprog.com/book/jfelm/programming-elm
My fears about the book being in bad shape were unfounded. PragProg don't have their usual forum up and running any more so they couldn't announce that there were updates, but seems like the author was on top of it, and released new chapters to the beta program last week. Now I can try #elm 0.19 again!
Part-time software engineer, part-time manager, part-time writer, full-time gobshite.
This is a Mastodon instance for tech people who are in, from, or connected in some way to Northern Ireland.