snabelen.no is one of the many independent Mastodon servers you can use to participate in the fediverse.
Ein norsk heimstad for den desentraliserte mikroblogge-plattformen.

Administrert av:

Serverstatistikk:

410
aktive brukere

#conda

0 innlegg0 deltakere0 innlegg i dag

#HDF5 is doing great. So basically:

1. Originally, upstream used autotools. The build system installed a h5cc wrapper which — besides being a compiler wrapper — had a few config-tool style options.
2. Then, upstream added #CMake build system as an alternative. It installed a different h5cc wrapper that did not have the config-tool style options anymore.
3. Downstreams that tried CMake quickly discovered that the new wrapper broke a lot of packages, so they reverted to autotools and reported a bug.
4. Upstream closed the bug, handwaving it as "CMake h5cc changes have been noted in the Release.txt at the time of change - archived copy should exist in the history files."
5. Upstream announced the plans to remove autotools support.

So, to summarize the current situation:

1. Pretty much everyone (at least #Arch, #Conda-forge, #Debian, #Fedora, #Gentoo) is building using autotools, because CMake builds cause too much breakage.
2. Downstreams originally judged this to be a HDF5 issue, so they didn't report bugs to affected packages. Not sure if they're even aware that HDF5 upstream rejected the report.
3. All packages remain "broken", and I'm guessing their authors may not even be aware of the problem, because, well, as I pointed out, everyone is still using autotools, and nobody reported the issues during initial CMake testing.
4. I'm not even sure if there is a good "fix" here. I honestly don't know the package, but it really sounds like the config-tool was removed with no replacement, so the only way forward might be for people to switch over to CMake (sigh) — which would of course break the packages almost everywhere, unless people also add fallbacks for compatibility with autotools builds.
5. The upstream's attitude suggests that HDF5 is pretty much a project unto itself, and doesn't care about its actual users.

github.com/HDFGroup/hdf5/issue

When building hdf5 with autotools, the following file is used to produce h5cc and friends: https://github.com/HDFGroup/hdf5/blob/develop/bin/h5cc.in However, when building with cmake, the following...
GitHubh5cc is severely lacking when building hdf5 with cmake, breaking downstream users · Issue #1814 · HDFGroup/hdf5Av BtbN
I don't get #Python package dependencies. I have two #conda envs with exactly python versions, packages all from #pip with major overlaps. Tried install another package in env A, after downgrading several packages including #pandas all went well. But when I try loading the newly installed package in REPL cmd, an error occurred complaining about pandas version. I removed the package, deactivate env A and activate env B, install same package in env B, same downgrade happened with pandas while this time all packages loaded without any issue. And this is not the first time I see this. Before this I use conda/mamba to manage packages and I switched to pip for package management hoping this won't happen anymore.

As part of a submission to @joss I had to explore using #conda to build #software for the first time.

I have always been reticent to use it (I like pip for python, and much of my work is on #HPC where environment modules are king.

I wrote a short post reflecting on what I learnt and my new opinions on conda: jackatkinson.net/post/ponderin

jackatkinson.net · Pondering CondaSome ruminations on conda following use in a recent project