Replace import $file syntax with flat package namespacing
#4462
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
lihaoyi
force-pushed
the
no-import-file
branch
from
c7bef4f to
1b625ba
Compare
lihaoyi
force-pushed
the
no-import-file
branch
from
c569694 to
fac3010
Compare
lihaoyi
changed the title
import $file syntax in favor of direct namespacingimport $file syntax with flat package namespacing
lihaoyi
force-pushed
the
no-import-file
branch
from
a518259 to
7f64e4d
Compare
lihaoyi
force-pushed
the
no-import-file
branch
from
4486ff4 to
c4bff49
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #4459
Fixes #3894
With this PR, all
.millfiles in a folder are in the same flatpackagenamespace, similar to how normal Scala files work. The previousimport $filesyntax was inherited from Ammonite, and unfortunately never took off across the Scala community. In effect this makes.millfiles behave almost exactly like.scalafiles, which is part of the longer term goal of removing special handling for.millfiles.The code generation for the helper files is not changed at all in this PR, rather we just make use of Scala 3's
exportclauses to make them available under the mainbuild.mill/package.millfile as wellThere is the caveat that the
package objects in.millfiles can be referenced viabuild.foo.barwithout the trailing.package. Implementing this caveat is the cause of a lot of the hackiness in the codegen, which will hopefully go away once the upstream language feature lands scala/improvement-proposals#100We leave the codegenned
import _root_.{build_ => $file}in place soimport $filewill continue to work to ease in the migration, but are no longer the recommended way of referencing helper files