-
Notifications
You must be signed in to change notification settings - Fork 323
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
Change layout of local library search path in order to be able to move Round_Spec.enso
back to Tests
#7634
Conversation
cfa30ad
to
e6dc959
Compare
As of commit e6dc959 I was able to run:
Now to change the default search paths to make the env var override unnecessary. |
3d4704c
to
66dac58
Compare
Round_Spec.enso
back to Tests
, try linking Tests
from Table_Tests
Round_Spec.enso
back to Tests
…local libraries next to current project
…ocalLibraryManager (creating vs finding created libraries)
66dac58
to
b5bf679
Compare
} | ||
|
||
"LocalLibraryManager" should { | ||
"find the libraries it has itself created" in { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test is partially redundant with
Line 55 in 5dc2c4c
"create a library project and include it on the list of local projects" in { |
So IMO it may make sense to keep both - the role of the newly added one is to ensure the logic for creating a library is kept in-sync with the logic for resolving them. The other test is just an integration test checking library management.
@@ -17,6 +16,8 @@ from Standard.Database.Errors import all | |||
from Standard.Test import Test, Problems | |||
import Standard.Test.Extensions | |||
|
|||
import enso_dev.Tests.Data.Round_Spec |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm really glad we could get this working 😀
I think this also opens up doors to more logic sharing where we can import parts of tests from Tests
in other test suites like Table_Tests
.
license: MIT | ||
author: enso-dev@enso.org | ||
maintainer: enso-dev@enso.org | ||
prefer-local-libraries: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another, IMO better, way to do this would be to declare the depended-on library in the edition override:
edition:
extends: 2023.123-dev
libraries:
- name: enso_dev.Tests
repository: local
However to do so, we need to specify some edition (like 2023.123-dev
example), but we don't really have one to specify. I guess we should extend the edition resolution to be able to specify extends: default
. Currently that is not possible, but it should be a relatively simple extension.
@jdunkerley @JaroslavTulach shall I create a ticket to allow extends: default
? Seems +- aligned with the direction #7639 is going in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shall I create a ticket .... aligned with the direction https://github.com/orgs/enso-org/discussions/7639 is going in.
#7639 discusses incompatibilities between engine & IDE. I am unsure how that relates and affects editions. If an existing concept like prefer-local-libraries
works, it is easier to suggest to use it than think about consequences of changing extends
mechanism.
CHANGELOG.md
Outdated
@@ -923,6 +923,8 @@ | |||
- [Only use types as State keys][7585] | |||
- [Allow Java Enums in case of branches][7607] | |||
- [Notification about the project rename action][7613] | |||
- [Changed layout of local libraries directory, making it easier to | |||
reference projects next to each other][7634] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Supporting depedencies among sibling projects
if (Files.exists(libraryPath)) { | ||
// TODO [RW] we could try finding alternative names (as directory name does not matter for local libraries), to find a free name | ||
// This can be done as part of #1877 | ||
throw new RuntimeException("Local library already exists") | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The issue #1877 was closed some time ago as part of a cleanup, but it indeed remains unsolved - there are a few TODOs referencing it and indeed the error handling in that part is not fully developed but a shortcut.
It may be worth to re-open the issue. However, this part of the API is not yet being used by the IDE. I guess we may wait until it starts being used to re-visit these improvements. But let's keep in mind there is some missing functionality there that should be filled-in once this is actually used.
# Conflicts: # CHANGELOG.md
…r projects interfering with expected values)
Pull Request Description
Round_Spec.enso
from publishedStandard.Test
into ourtest/Tests
project; theTable_Tests
that depend on it, simplyimport enso_dev.Tests
.root/<namespace>/<name>
.root/<dir>
- the namespace and name are now read frompackage.yaml
instead.ENSO_LIBRARY_PATH
.ENSO_HOME/lib
still takes precedence.prefer-local-libraries: true
or add the other local project to its edition. The edition resolution logic is not changed.Important Notes
Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:
Scala,
Java,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
./run ide build
.