Why two separate libraries for `result` and `maybe`

[demetere]

My question concerns the initial decision to split result and maybe into two separate repositories/libraries. From my understanding, both encapsulate the concept of railway-oriented programming. I believe it would be much simpler if they were merged into the result library, as I currently need both in my project.

I'm highlighting this issue because I encountered problems running pytest on this library. Specifically, rustedpy-maybe is defined as maybe under the src directory. As a result, pip install -e . doesn't work correctly since it tries to find rustedpy_maybe under src, fails to locate it, and causes conflicts. I have already merged the two projects locally, but this isn't backwards compatible because instead of using from result import *, you now have to use either from result.result or from result.maybe. If we agree to merge these two projects, we need to decide on the approach. We could maintain from result import * and add from result.maybe separately, but I believe it's better to import explicitly.

What are your thoughts on this? I've already created a function maybe(v: T | None) -> Maybe[T] (issue #4) and two decorators as_maybe and as_async_maybe (issue #1). Everything is tested and type-hinted, so if we decide to proceed, I can submit a comprehensive pull request to the result library containing all these changes.

Alternatively, if you prefer to first implement these changes in the current library before considering a merge into result, we need to address the naming issue. One solution could be to rename src.maybe to src.rustedpy_maybe, or perhaps you have another workaround in mind?

[francium]

Currently the projects are setup to be ship separately, result and rustedpy-maybe (I failed to contact the owner of 'maybe' PyPI project, so we weren't able to acquire that name).

I don't have any intention to merge the two projects as you mention, I don't think there's any need currently, but that may change in future depending on how things go. But right now, I'm going to keep the separate.

We may benefit slightly from reducing some duplicate project files if the two were merged, but given this library is not used by many people, I don't want to put in the effort doing all that work until it's absolutely necessary or someone (such as yourself perhaps) volunteers because you're actually using this library in a real project.

If anyone wants to use both result and rustedpy-maybe, they'll need to just install both. I don't want to create a single library with multiple things in it (result, maybe, plus more things in the future?). Maybe this will change in the future, but not right now.

We also have a really good name, result, but that name doesn't make sense if we put the maybe inside the same result library.

initial decision to split result and maybe into two separate repositories

There was no decision to split. Result was created back in like 2016 by the original author and this maybe library was created last year because someone asked for it. This maybe library is used by very very few people: https://pypistats.org/packages/rustedpy-maybe compared to result: https://pypistats.org/packages/result

I'm highlighting this issue because I encountered problems running pytest on this library. Specifically, rustedpy-maybe is defined as maybe under the src directory. As a result, pip install -e . doesn't work correctly since it tries to find rustedpy_maybe under src, fails to locate it, and causes conflicts

The issue you're describing isn't what I've encountered before. Here's what I did,

python -m venv venv # create a new virtualenv

source venv/bin/activate # activate the virtualenv

make install # I just added the Makefile now, see https://github.com/rustedpy/maybe/blob/master/Makefile

make test # Should work correctly

cd result
pip install -e . # now you should be able to install result in the same virtualenv as well

It could be you've got a very polluted virtualenv (or you're not using a virtualenv at all!?). Always use a virtualenv (or a virtualenv manager like Poetry), Python's dependency system isn't great and running pip without a virtualenv is going to cause problems eventually with your OS.

Run pip list to see what's installed in your virtualenv (or in your non-virtualenv environment if you're not using a virtualenv)

[francium]

If you have any problems while working on a PR for specific issue, just post a comment there and I'll try to help.