Add py:
prefix as namespace for our own PyScript packages
#2061
Replies: 2 comments 1 reply
-
@laffra (given mention of ltk) may also have opinions. If I remember, @fpliger wasn't 100% certain the names |
Beta Was this translation helpful? Give feedback.
-
amend the That, in turns, allow |
Beta Was this translation helpful? Give feedback.
-
AFAIK in micropip or pip in general, packages with a colon in the name are not allowed, meaning if this is the RegExp for a package name
^([A-Z0-9]|[A-Z0-9][A-Z0-9._-]*[A-Z0-9])$
we should be good by deciding thatpy:web
, as example, as configpackages = [...]
entry should never collide or interfere with other packages in the wild.There is previous work in the JS world too, see
node:fs
VSbun:fs
or other "protocols" used to disambiguate the final package to use, hence I am pretty confident this is not a terrible idea.Why
Our core is growing and growing but not everyone will need
pyscript.pyweb
, as example, among others, but we do have the possibility to pre-parse the config and instrument it so that:py:
prefix will be removed from the packages list that will use the native underlying way to import packages on bootstrapzip
ortar.gz
folder that contains everything they need to work and we sneakily move and orchestrate those packages through thefiles
entry in the config, augmenting it to bootstrap via unzip/untargz operations the dependencypyscript
exports but (imho) we'd be also good to havepyweb
as result so that one simplyimport pyweb
whenpy:web
package is definedltk:core
orltk:thing
namespace too, it's up to us how many prefixes we want to enable, as long as those modules are properly archived and available via CDN too (or for offline usage as well)I think the only thing to solve, if everyone agrees on this way forward, is to decide how we can also make those packages related JS modules available, but I think we could simply decide ourselves that those packages will have a list of modules defined as
[js_modules]
(let's say that's the optionaljs_modules.toml
file that should be present at the root of the unzipped package) so that we can also instrument that field in the resulting config and everything should play out as smoothly as possible and as transparent (for users) as possible.The convention for ourselves is then:
pyweb
folder__init__.py
in there and every other file that's neededjs_modules.toml
(orjs_modules.json
) at the root of that folderpy:
packages from thepackage
field and will instead automatically extract those folders in the virtual FSjs_modules.*
is found, those modules augment the already availablejs_modules
entry in the config or create one if not there yetpackages = ["py:web"]
in their config and they are good to go@fpliger, @ntoll, @JeffersGlass, @mchilvers, what are your thoughts around this proposal?
Beta Was this translation helpful? Give feedback.
All reactions