search

com-lihaoyi / mill

Mill is a fast JVM build tool that supports Java and Scala. 2-3x faster than Gradle and 5-10x faster than Maven for common workflows, Mill aims to make your project’s build process performant, maintainable, and flexible
https://mill-build.org/
MIT License
2.06k stars 339 forks source link

Can we reduce the friction between `mill.api.PathRef` and `os.Path`? #3816

Open lihaoyi opened 3 days ago

lihaoyi commented 3 days ago

e.g. making one a subtype of the other would remove the need for a lot of tedious .path extraction, especially if we provide a Shellable instance for it

Alternately, what if we got rid of PathRef altogether, and just made the JSON serializer for os.Path do what PathRef does today? We might need to tweak things so e.g. the hashcode is computed from the JSON serialized output rather than calling .hashCode on the value

Not clear what the best thing to do here, but I think there's definitely room to reduce some friction juggling between Paths and PathRefs

lefou commented 2 days ago

I don't think we want to blur the difference between the two. I think the primary motivation for PathRef is to have an appropriate content tracker for paths, whereas os.Path is representing the path itself, but not the content. If we merge both, we will no longer be able to express in an API, what we are interested in. Also the result of tasks may be less specific and may invalidate unnecessary often, e.g. when only the path is needed, but a PathRef is returned.

lefou commented 2 days ago

If convenience is needed, we could think about adding some convenience API to PathRef, e.g. a way to assemble sub-paths. But in the end, the explicit .path might still be what we really want in terms of clarity.