Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider splitting out !-notation into separate repo? #66

Open
benhutchison opened this issue Mar 30, 2018 · 11 comments
Open

Consider splitting out !-notation into separate repo? #66

benhutchison opened this issue Mar 30, 2018 · 11 comments

Comments

@benhutchison
Copy link

Currently, DSL bundles alot of loosely related functionality together. I would like to access the !-notation feature in a modular way.

I didn't grasp the benefits of the !-notation when you first presented at REA FP guild (in the Each project), but I have since better understood the potential and would like to trial it. I write mostly monadic code nowadays, so any way to reduce "friction" can have a big payoff.

However, Im not going to take such big dependency as whole of DSL ATM, but if !-notation was more modular I would try using it (Ive been burned by large codebase dependencies in the past, most notably Finagle which didnt support 2.11.x for ages, just because some small parts of it didnt).

Please consider splitting out !-notation and supporting machinery (eg reset all plugin) into separate repos/artifacts.

@Atry
Copy link
Collaborator

Atry commented Mar 30, 2018

They are separate artifacts but not separate repositories at the moment.
Do you suggest to split them into different repositories?

@Atry
Copy link
Collaborator

Atry commented Mar 30, 2018

The current code base is modular at the artifact level.
https://github.com/ThoughtWorksInc/Dsl.scala/blob/master/build.sbt#L26

Most of keywords depend on only the core Dsl library or Shift keyword.

@benhutchison
Copy link
Author

benhutchison commented Mar 30, 2018 via email

@Atry
Copy link
Collaborator

Atry commented Mar 30, 2018

If I understand correctly, the actual need is separating version number.

@benhutchison
Copy link
Author

What Im after is "confidence that the libraries I depend upon will be not entangled with unrelated code or concerns."

That's broader than just a technical concern, it also touches on project culture & human behavior.

I feel that many aspects of multiple-projects-in-single-repo encourage entanglement, and its only through careful discipline that unrelated libraries in same repo can remain modular.

Examples of issues:

  • Shared releases across unrelated libraries (as in DSL at present)
  • Github Releases are per-repo so encourages this behavior as a default
  • A build.sbt file assumes a single shared scalaVersion
  • Single queue for PRs across all subprojects
  • Single README file means docs cannot focus on a single library or tool

While many of these can be overcome, the defaults for a github repo all encourage entanglement.

@Atry
Copy link
Collaborator

Atry commented Mar 30, 2018

Fair enough! However multiple of repositories also means multiple of efforts to maintain those repositories.

Would you like to be a maintainer of some of the split projects?

@benhutchison
Copy link
Author

benhutchison commented Mar 30, 2018 via email

@Atry
Copy link
Collaborator

Atry commented Apr 1, 2018 via email

@benhutchison
Copy link
Author

benhutchison commented Apr 1, 2018 via email

@Atry
Copy link
Collaborator

Atry commented Apr 2, 2018 via email

Atry added a commit to Atry/Dsl.scala that referenced this issue Jun 10, 2019
Atry added a commit to Atry/Dsl.scala that referenced this issue Jun 10, 2019
@Atry
Copy link
Collaborator

Atry commented Jun 10, 2019

The cats library has been moved to a separate repository https://github.com/ThoughtWorksInc/dsl-domains-cats

Atry added a commit that referenced this issue Jun 10, 2019
Move domains-cats to another repository (related to #66)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants