Add extractBase64 to 0.4 so 0.4 and 1.0 can be targeted by same code

[tomjaguarpaw]

I would love stan to be able to support both base-6.4 series 0.4 and series 1.0 at the same time. Currently I think that means I have to use CPP and do this:

#if MIN_VERSION_base64(1,0,0)
extractBase64 :: Data.Base64.Types.Base64 k a -> a
extractBase64 = Data.Base64.Types.extractBase64
#else
extractBase64 :: a -> a
extractBase64 = id
#endif

and then use extractBase64 . Base64.encodeBase64 everywhere I previously used just Base64.encodeBase64. This works, but with support from base64 this could be significantly easier.

Would you be willing to add Data.Base64.Types, containing

-- | This is a compatibility shim to allow client code to target
--   both base-0.4 and base-1.0 at the same time.
extractBase64 :: a -> a
extractBase64 = id

to the 0.4 series (i.e. release 0.4.3.0 containing this)? Then extractBase64 . Base64.encodeBase64 works fine on both versions.

I'm willing to contribute the code if this approach is acceptable to you.

---

There may be some other functions that would benefit from this approach too, but encodeBase64 is the only one I need for stan.

[emilypi]

hi @tomjaguarpaw! I'm genuinely confused as to why you'd want to support two major epochs of base64. I'd rather not commit useless code to my library to support one tool or another for compatibility's sake. This to me sounds more like a feature to add to stan if it doesn't already exist. Otherwise major version api changes are untenable to support in future iterations of a library without this kind of change!

[tomjaguarpaw]

I'm genuinely confused as to why you'd want to support two major epochs of base64

I'm genuinely confused why you think I wouldn't! I'd like to release a version of stan that works with base64-1.0 since it's the latest version. However, I don't want to force users who use stan as a library to upgrade from base64-0.4. They might not be able to if they have other dependencies that haven't upgraded to base64-1.0 yet.

Is there another way I can release a version of stan that supports base64-1.0 but still allows users to use it as a library in combination with other dependencies which require base64-0.4? Or is this something you think is just not worth doing? (Besides CPP in stan, which is my current approach, or releasing a compat library).

This to me sounds more like a feature to add to stan if it doesn't already exist

I'm not sure what you mean. How do you envisage this could be a feature of stan?

Otherwise major version api changes are untenable to support in future iterations of a library without this kind of change!

I don't understand that sentence at all, I'm afraid.

[emilypi]

I'm genuinely confused why you think I wouldn't! I'd like to release a version of stan that works with base64-1.0 since it's the latest version. However, I don't want to force users who use stan as a library to upgrade from base64-0.4. They might not be able to if they have other dependencies that haven't upgraded to base64-1.0 yet.

Are there stan library users? I see nothing in the reverse deps for stan that would attest to this being a real use case - I thought this was primarily an executable used for static analysis geared towards a CI pass more than library usage. I hesitate to commit what amounts to garbage into my codebase specifically for a single downstream user with an unsupported theoretical use that, frankly, doesn't make a ton of sense from a code perspective. People need to migrate. It's been long enough.

Is there another way I can release a version of stan that supports base64-1.0 but still allows users to use it as a library in combination with other dependencies which require base64-0.4?

What you can do downstream is have something like

#if MIN_VERSION_base64(1,0,0)
stanEncodeBase64 :: ByteString -> ByteString 
stanEncodeBase64 = Data.Base64.Types.extractBase64 . encodeBase64
#else 
stanEncodeBase64 :: ByteString -> ByteString 
stanEncodeBase64 = encodeBase64
#endif 

In your library, and use that. Then, we don't have a problem.

Or is this something you think is just not worth doing?

Consider this from my perspective: people have known these changes were coming for almost 2 years, with an RFC detailing the proposal 1.5 years ago. I'm not interested in keeping users on an inferior library experience for longer than I already have.

I'm not sure what you mean. How do you envisage this could be a feature of stan?

I misunderstood the use case you were thinking of. i was thinking "static analysis of libraries using multiple epochs", not "library users supporting old versions". Both, I question.

I don't understand that sentence at all, I'm afraid.

You have to rip the bandaid off at some point. What happens when base64-1.1 comes out and users expect to still be on 0.4.2.1? Do we support them to? Do I continue to commit cruft to my library to support that narrow use case? This is what I mean. It's unscalable for me to baby downstream code - even stan.

[emilypi]

Closed because I fail to see how twitter callouts are necessary in what I thought was a goodwill line of communication.