Closed gadenbuie closed 6 months ago
Thank you for your comments and suggestions @wch, they were super helpful! I've addressed and resolved them all, except for two bigger items that I'll call out because they might be hard to find in the UI above.
We've identified some weirdness around the dual-purpose app
argument in encode_shinylive_url()
. As it was reviewed, it could be a file on disk or the contents of a hypothetical app.py
or app.R
. I tried an alternative approach that's more consistent, but I'm worried this has user experience tradeoffs. https://github.com/posit-dev/py-shinylive/pull/20#discussion_r1443852134
We updated the imports to use typing_extensions
for Python < 3.11, but this is causing issues in CI (that I've resolved!). https://github.com/posit-dev/py-shinylive/pull/20#discussion_r1443852134. In doing this, I realized the type we were adjusting already existed in this project and suffers from the same problem https://github.com/posit-dev/py-shinylive/blob/373f639ed81336f2a1393b9726d2a2a1dc48a0b9/shinylive/_app_json.py#L12-L17 https://github.com/posit-dev/py-shinylive/blob/373f639ed81336f2a1393b9726d2a2a1dc48a0b9/shinylive/_url.py#L11-L23
I've figured out the issue with pip install -e .
and typing_extensions
:
version = attr: shinylive.__version__
in setup.cfg
https://github.com/posit-dev/py-shinylive/blob/a959c07873a3f2ecb3dbb518c7fc840ead27e415/setup.cfg#L3pip
generates metadata for the package and it needs to load shinylive
to determine the package version.type_annotations
, which hasn't been installed yet, causing the ModuleNotFoundError
.It took a bit of exploration, but I've come up with what I think is a pretty good solution:
shinylive.version
.setup.cfg
we call version = attr: shinylive.version.SHINYLIVE_PACKAGE_VERSION
and in other places we import the constants from .version
instead of ._version
.pip
can find the package version in the version
subpackage without having to evaluate the code in the main shinylive
package.For the typing_extensions
issue, I believe you should be able to do what we do in shiny, and list it in install_requires
:
https://github.com/posit-dev/py-shiny/blob/592cf34397606eed98c1488799e495754ebf8a1f/setup.cfg#L34-L35
I had forgotten that that typing_extensions
isn't part of the Python standard library, and so it needs to be listed as an explicit dependency.
For the
typing_extensions
issue, I believe you should be able to do what we do in shiny, and list it ininstall_requires
: posit-dev/py-shiny@592cf34
/setup.cfg#L34-L35I had forgotten that that
typing_extensions
isn't part of the Python standard library, and so it needs to be listed as an explicit dependency.
@wch Did you see my last comment above? (I know there's a lot going on in this PR its easy to miss.)
In short, it's not about install_requires
but rather how shinylive uses a dynamic version that requires pip
to run the module code. In other words, I found the source of the problem we paired on together last week and I have a pretty good fix for it.
I've figured out the issue with
pip install -e .
andtyping_extensions
Wait, do you mean the lzstring
issue? (I don't recall typing_extensions
being a problem when we paired on it last week but I could be missing something.)
Yeah, we hadn't added typing_extensions
yet, but once we did we resurfaced the same problem we had with lzstring
. Fundamentally they're caused by the same thing (see above for description). With lzstring
, we could move the import statement into a function and delay its evaluation; with typing_extensions
we can't use that strategy so I had to figure out the root cause.
Hm, it's strange that the same thing happened with typing_extensions
-- for shiny and a number of other packages, we use version = attr: shiny.__version__
, and that works fine. I think the fact that it's not working here is a symptom of something else that's weird. I'll take a deeper look into it.
@wch What's different about py-shiny
is that __version__
is set to a literal value:
__version__ = "0.6.1.9000"
Here in py-shinylive
it's set a to an expression, which then forces pip
to evaluate some of the packaged code to determine the value. The problem also goes away if we were to do the same here and set __version__
directly rather than storing the version numbers in a separate variable.
Ah, OK, I see. That sounds good then. Can you you rename version
to _version
?
Adds
shinylive url
, a command group toencode
(or create) a shinylive.io URL for Python or R apps from local files ordecode
the existing URL. The core functionality is wrapped inencode_shinylive_url()
anddecode_shinylive_url()
which are exported to facilitate creating and decoding shinylive URLs from within a Python session (the primary use case is for the Component and Layout galleries, but I'm sure this would be broadly useful).Examples
Copy the multiple files Python app example link:
Copy this example Shiny app
and then generate a link and open it on shinylive
Try the same idea, but with this R app
Or apply the same idea to a local app on your computer. In this case, the language is inferred from the file extension.