Sonic-pi: 3.2.1: compile-extensions.rb fails (`require': cannot load such file -- rake (LoadError))

[dvzrv]

This commit introduced a bunch of code in the top of the file that is now failing for me:

/usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in `require': cannot load such file -- rake (LoadError)
        from /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in `require'
        from ./compile-extensions.rb:23:in `<main>'

As soon as I remove lines 19 to 25 the extensions compile again for me. I think those lines should have been removed in this commit again, as everything else that they were introduced for got removed.

[rbnpi]

Things have moved on a bit since then. fast_osc has now been abandoned, and compile-extensions.rb changed see commit #4096. I suggest you rebuild from the tagged 3.2.1 commit

[dvzrv]

See title: I'm building the 3.2.1 release.

I'm not entirely sure which commit you are referring to. 4096 is neither a pull request nor an issue.

I'm aware of fast_osc being abandoned. However, the cleanup to remove it was not complete (see the first and last link in my initial comment).

[xavriley]

To clarify fast_osc isn’t abandoned, it just needs some work before it’s included again :)

On 31 Mar 2020, at 09:46, David Runge [e-mail] wrote:



See title: I'm building the 3.2.1 release.

I'm not entirely sure which commit you are referring to. 4096 is neither a pull request nor an issue.

I'm aware of fast_osc being abandoned. However, the cleanup to remove it was not complete (see the first and last link in my initial comment).

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/samaaron/sonic-pi/issues/2310#issuecomment-606482397, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAC2G53M47B2A6T35UMQCKDRKGTUPANCNFSM4LXJTSZA.

[samaaron]

I've now removed the code that referred to rake and re-tagged v3.2.1

Hopefully that should fix things up for you :-)

[dvzrv]

On 2020-03-31 02:34:45 (-0700), Sam Aaron wrote:

I've now removed the code that referred to rake and re-tagged v3.2.1

Argh, please don't retag versions!

This breaks reproducibility downstream (the tarball checksum changes).
Why not just tag v3.2.2?

[samaaron]

v3.2.1 isn't officially out until the 3rd of April

[dvzrv]

On 2020-03-31 02:40:39 (-0700), Sam Aaron wrote:

v3.2.1 isn't officially out until the 3rd of April

Why is it tagged as a stable release then?

In case you would like to do a pre-release, why not use what semver
offers and use e.g. v3.2.1-beta1 or v3.2.1-rc1, followed by a v3.2.1 on
the 3rd of April or whenever you would like to release the version?
For reference: https://semver.org/

Retagging is really bad development practice and breaks reproducibility/
chain of trust for everyone that tries to build and use this software.

Not adhering to semver best practices and then expecting people to infer
some random system about when a release is "officially out" is not user
friendly either.

[samaaron]

I'm very much aware of semver. I don't really fully agree with it - especially as a system to be religious about.

I'm not expecting anyone to infer anything - rather it's good to talk. Software is not a mathematical lattice of truth - it's also very much a social phenomenon.

[rbnpi]

Sorry @xavriley I meant "abandoned for now" to get 3.2.1 out the door. It will certainly be good to have it back again when fully working. I know you've done lots of work on this over the years.

[dvzrv]

I'm very much aware of semver. I don't really fully agree with it - especially as a system to be religious about.

I find it odd and pretty condescending to call following a simple versioning scheme and people then relying on that as "religious". If anything, this is just very technical, nothing more.

I'm also baffled by calling this "religious" in regards to following a trust chain (a tag doesn't change because it points to a specific commit) especially when a downstream relies on verifiable tarballs, so that their build systems don't just arbitrarily download junk from the internet and so that people are able to reproducibly build the exact same version of software themselves.

I'm not expecting anyone to infer anything - rather it's good to talk.

Well, but you did exactly that: You let me waste time on a version, that (according to you) is supposed to be a pre-release. Without marking it as such, I have no way of knowing, that it is a pre-release.
In regards to semver and "I don't really fully agree with it": So, where is your take on how the release process is regulated then? Is this written down somewhere?

And sure, it's good to talk. However, I would rather have a conversation about useful things then and not about re-occuring guess work.

Software is not a mathematical lattice of truth - it's also very much a cultural phenomenon.

To make an analogy: We also wouldn't start counting versions backwards and justify it by being a "cultural phenomenon", just because we can.

Maybe you're confusing the user story (a cultural phenomenon of using a software for a certain purpose or another) with the developer story (engineering a piece of reliable software, that is built, distributed and installed). Sure, both stories have a cultural aspect to it, but especially the developer story is very technical and there are established standards, that you can't just throw overboard, especially if you don't provide a documented solution replacing it.

[dvzrv]

I have now rebuilt the 3.2.1 version and re-released the package.
@samaaron Thanks for the fix!

I apologize if my comments came across as rude.

Furthermore, I'd be happy, if you would consider semver's pre-release terminology no re-tagging in the future, as it eases the maintenance burden on downstreams. Thanks!