Plan for releases about stb_image HOT 15 CLOSED

I was thinking about the following situation, suppose a project uses img_decode with stb_image in the first place, and later the author found that they need to decode some image formats that are only available in the image_rs backend, then they can simply replace the dependency entry to :img_decode_rs without changing the module name in their code.

If you want it to work like this, then they should have the same application name, this way Elixir/Mix will force them to pick one or the other.

Otherwise, you need different app names and different module names. Both should be fine!

from stb_image.

Right, protocols are behaviours + custom dispatch. A behaviour would be enough but both require a third package.

If you want only two packages, the options are to keep both packages completely independent OR make them have the same application name and same modules. :) Either way is fine I think!

from stb_image.

I'm thinking about keeping this as a single library and refactoring it a bit to allow users to select the backend at compile time.

I wonder if there was any recommended way on how to organise this kind of project in Elixir? Would it be be more preferable to have two standalone libraries or select the backend using config?

from stb_image.

We could also have img_decode, then img_decode_c and img_decode_rs, then the user has to declare img_decode and one additional package in their mix.exs, but that sounds too high maintenance. The option to keep it all here and use the configuration is less common but it may be fine for this project given the size?

from stb_image.

I see. Now I think maybe splitting this into two libraries is a better approach. I'll leave the C implementation in this repo.

from stb_image.

I have moved the image_rs backend into another repo. This repo now only contains the stb_image implementation. 😃

from stb_image.

Thank you!

Btw, img_decode_rs should define a separate application and a separate module, otherwise they will conflict. However, if you them to define the same module and application, you can do so by:

1. Changing the package name when publishing to hex to img_decode_rs
2. Keeping the application name as img_decode
3. Then tell people to use it as {:img_decode, "~> 0.1.0", hex: :img_decode_rs}

Which approach do you prefer?

from stb_image.

I am not sure if if my comment was clear, but just in case, if they are separate applications, then they should not have conflicting modules, but there is an option to keep the applications and modules the same, but have them be provided by different packages. :)

from stb_image.

Thank you!

Btw, img_decode_rs should define a separate application and a separate module, otherwise they will conflict. However, if you them to define the same module and application, you can do so by:

1. Changing the package name when publishing to hex to img_decode_rs
2. Keeping the application name as img_decode
3. Then tell people to use it as {:img_decode, "~> 0.1.0", hex: :img_decode_rs}

Which approach do you prefer?

I was thinking about the following situation, suppose a project uses img_decode with stb_image in the first place, and later the author found that they need to decode some image formats that are only available in the image_rs backend, then they can simply replace the dependency entry to :img_decode_rs without changing the module name in their code.

However, it is possible that some may want to use both libraries at the same time and use either one as a fallback when the other library failed to decode the image. Given this situation, I should change the module name to avoid conflicts.

But using unique module names seems to be better.

from stb_image.

I think I should make it more clear instead of using ImgDecode. ImgDecode here is like a protocol / interface / concept, and StbImage or ImageRs is just an implementation. But defprotocol thingy does not seem to be fit here..?

from stb_image.

You can define a behaviour but then you need a third package only for the behaviour, and I am not sure if it is worth it.

from stb_image.

Perhaps an analogy for this could be the POSIX API? You can use glibc from GNU or use uclibc, etc.

defprotocol is targeted at dispatching struct to the corresponding module, but here what I'd like to define is a universal APIs, such as from_file/1 and from_memory/1.

from stb_image.

You can define a behaviour but then you need a third package only for the behaviour, and I am not sure if it is worth it.

Yeah, that can be over-complicated. Let's keep it simple here - they are just two irrelevant libraries that happen to have some functions with the same signatures. :D

from stb_image.

I'm using the former approach as it would technically allow users to use the other as a fallback option.

from stb_image.

I'll probably close this issue for now. And time to make some minor changes in #25 PR of elixir-nx/scidata. 🎉

from stb_image.