-
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
Modify Import Syntax to Include Username Prefix #1767
Comments
I'd like to discuss a few things here (@wdanilo @MichaelMauderer @iamrecursion): Prefix for local projectsAn edge case that we have to handle is that one may create a project while not being logged in and want to import modules from that project. As we do not have relative imports, they will need an absolute path so the project itself needs a prefix. What should it be, since the user is not logged in? As far as I understand we do not want to force the user to log-in to create a new project and we also would prefer to avoid having to modify imports once the user logs in to rename the prefix. My suggestion would be to have a reserved prefix (much like Author field in Standard librariesAs far as I understand, we want the One solution that I'd suggest is having a separate field |
Prefix syntaxWe need to come up with criteria for the usernames/import prefixes. I'd suggest just |
I think this should take 2-3 days but I set 4 to be safe as this affects many parts of the engine so it's highly possible there will be unexpected issues. |
I like the
My concern with a separate |
If we're going with such a naming scheme, I would opt to change |
Right, so this is next on my plate, we need to make calls on the unresolved issues:
|
As far as I remember the
I think this may be a misunderstanding - to my understanding, |
Btw. we still have a problem with using author for the prefix - currently our spec allows multiple authors, as the So I think that we may need to add a separate field anyway, I'd suggest calling it |
The problem with this is that
TBH I don't understand this question – where were any sentences that we want to work around any of the described features? Also, what is the
I also don't like
That's right. We've been discussing that already with Marcin too. In fact, the name "Standard" was invented by Marcin during this discussion after me telling exactly this argument ;)
I fully agree with Ara here. Let's be config-less if that is possible. Telling which library belongs to "Standard" is our job (the core team). This should not live in user-maintaining configs. Instead, there should be a list of libraries on the server that will just contain all names of libs we consider to be "standard". This list would be updated by us. |
@wdanilo right, so here's where I'm confused. We talk about wanting the prefix to be Particularly the latter (a super awesome community member has to change their name to Which suggests to me that this should be a separate config field – like
|
We've discussed the issue with @wdanilo and the resolution is: the author prefix is going to be a separate entity in our libraries system, akin to GitHub's organizations, allowing users to alias their libraries with some organizational name, but defaulting to the username. |
I've been told that there were discussions that we want to be able to create aliases for library names, like for example when a user I'm not sure if I understand why we want this to be an alias instead of just publishing new versions of the library under a new name. Introducing the alias can be 1. confusing - is If we really want to have these aliases (although in my opinion this can be confusing to users as written above), I'd suggest not adding any logic for handling that just for this special case, but instead handling it by just creating copies of the library - so that when we assign But I would mostly suggest just renaming future versions of the library to @wdanilo AFAIK you were suggesting these aliases, what do you think about the above?
It is impossible to do this in a completely 'configless' way - at some place there needs to be this configuration file and it cannot be just on our servers - it must somehow reside on the local machine as the local machine must know how to resolve I guess an alternative solution could be to be just based on the directory, i.e. if the package is located in |
One more thought: Please note that the prefix is not only a notion of a library but also of a project - to have an unified import syntax, the project's module should also have some kind of a prefix. I thought that initially we wanted to go for the project's prefix to also be correlated with the author's username or if they are not logged in, fall back to some default. But if we don't want to include the prefix in the configuration, then how will we infer the prefix for a given project? For libraries we could check their directory structure (e.g. a library stored in parent directory Which one do you think we should go for? @wdanilo @iamrecursion @MichaelMauderer @kustosz I think your input could be very valuable here. |
The more I think about the default prefix, the more I think we should also implement the |
So we've discussed the above with Wojciech and the resolution is: this piece of syntax should be |
Summary
The libraries are meant to be identified by their author's username, so we want to support the syntax
import Library_Author.Library_Name.Some_Module.Some_Symbol
.All libraries will have an author, so we are not making the author prefix optional, instead - every import (of course besides polyglot imports as these are a separate thing altogether) will now need to contain that prefix.
In particular, the standard libraries will use the prefix
Standard
.Value
Specification
package.yaml
(the same as the library name is taken from there).Standard
library back into separate modules, all having theStandard
prefix.Acceptance Criteria & Test Cases
The text was updated successfully, but these errors were encountered: