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

Transitive dart dependencies #280

Closed
cgrand opened this issue Oct 23, 2023 · 6 comments
Closed

Transitive dart dependencies #280

cgrand opened this issue Oct 23, 2023 · 6 comments

Comments

@cgrand
Copy link
Contributor

cgrand commented Oct 23, 2023

The problem is allowing a package (typically a CLJC package) to declare dependencies to a Dart package and this dependencies declaration to be preserved irrespective of the packaging and of the number of intermediate dependency.

When a clojure lib is packaged as a jar, only "classes", resources are preserved. deps.edn is lost. pom.xml is sometimes embedded under a descendant path of META-INF. Whatever we need we should put it under META-INF.

We could write in MANIFEST.MF but this would mean being dependent on the packaging of the lib and we would need something else for git or local deps.

We'd like to be be able to add dart deps under :deps in deps.edn. But it's unclear how to make it participate to tools.deps.
Even if it's not critical, dart deps are not namespaced, they use a single identifier but tools.deps complain about non-namespaced symbol so it could mean using symboles like pub/shared_preferences.

We are not interested into publishing clj libs to pub.dev so dart deps don't make sense for tools.deps in general to care about dart deps. Thus it may be easiest to follow the same route as shadow-cljs and use a :dart/deps key.

@momerath42
Copy link

I don't know about others, but only the local/root case matters to me (and it would definitely be nice to have soon); I'd be happy to work on this, if it's a good candidate for getting my feet wet.

@cgrand
Copy link
Contributor Author

cgrand commented Oct 23, 2023

After more thoughts on the problem:

  • having our own file (not deps.edn) simplifies packaging but we lose some integration, we think the trade-off is ok because it only impacts authors of cljd libraries using dart deps
  • we use resolve-deps to get a map of libs to paths
  • we scan all deps for pubspec.yaml
  • we create dummy projects under .clojuredart that we add as local deps to pubspec
  • we name the dummy projects after either a she or the project name or both

@dupuchba
Copy link
Contributor

@momerath42 that's very nice but I think but we need it ASAP so we are going to do it. But we could need some help on review, testing, design & co

@cgrand cgrand mentioned this issue Oct 24, 2023
@momerath42
Copy link

a76c09a is working great, with a bunch of dart dependencies pulled in from my other (root/local) project, as well as use of several of its .cljd files. Thanks!

@cgrand
Copy link
Contributor Author

cgrand commented Oct 24, 2023

In a76c09a we implemented a way to handle dart dependencies (transitively across deps.edn).

For lib users: it should just work, add the lib to deps.edn and the next cljd command (compile, flutter, clean) will retrieve dart deps if needed.

For lib authors:

  • declare dart deps in pubspec.yaml as usual
  • when packaging as a jar, copy pubspec.yaml on the classpath before building (or add it to the root of the jar)

@dupuchba
Copy link
Contributor

[ ] TODO: document it

@cgrand cgrand closed this as completed Jun 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants