Py37 support for cryptography

[danlamanna]

Related: #48

Now that lambda has supported Py37 for a while lambda-packages should have a cryptography package for 3.7.

[caillef]

That's definitely something missing for my project. Is there something I can do to solve this ?

[Jone1]

I also need it.

[eyelidlessness]

Note that if we did this we would need a way to differentiate between custom elements that should be server rendered and those that should not. I think we should not server render lower case tag names by default, they should be treated as simple HTML. However some sort of :static property might be a way to opt-in.

I don’t think it needs to be this complicated. Custom element names require a hyphen. If you’re already relying on component naming conventions to determine whether something is a component, I’d assume you could just add hyphenation to the heuristic.

This does raise an interesting question though about plain .html imports, especially with declarative web components on the standards track and making their way into Chrome (behind a flag).

[matthewp]

My point is that how do we know the user wants to server render the component. Custom elements are often used for enhancement purposes where server rendering isn't necessary, for example a date picker doesn't need server rendering. We need a way to signal intent, like we have with pascal case framework components. Maybe this is an argument for needing to use custom elements with pascal case like all the others when server rendering.

[eyelidlessness]

Ah I see your point. IMO this would be easier to address with something like #73, as Astro could support multiple props (e.g. :static :load) to signal intent for both server and client. I guess in theory even without that you could just stack them, like <foo-component:static:load ...>. Not sure how much that's a footgun.

[matthewp]

I'm curious how people are feeling about this now that we've had some time to launch Astro. Should we bring a Lit renderer into the monorepo? Into core? I think these options are all possible:

1. The lit renderer is a 3rd party renderer (by me, under my personal npm namespace).
2. The lit renderer is in the monorepo but not included by default.
3. The lit renderer is in the monorepo and included by default.

Imo, (3) should not be done, at least not yet. SSR support in Lit is in the rc phase. We should at least wait until its released as stable before bringing it in.

That leaves either (1) or (2), and I don't have a strong preference. I think including it in the monorepo eventually is a good idea, but I can see an argument for waiting until it's stable.

cc @natemoo-re @drwpow @FredKSchott

[backlineint]

When initially experimenting with Astro I was looking into how to use Lit with it and came across this issue. My hope was for (2) - a renderer in the monorepo but not enabled by default (at least not until Lit SSR is released as stable.)

[FredKSchott]

Right now we’re in this weird place where every renderer slows down startup time regardless of whether you need it. Until we have esbuild-powered dependendency handling, I’m hesitant to add more built-in renderers.

@backlineint points out the other issue with all of our built in renderers: no control over framework version. Since we tied renderer version to framework version, I think this may be a larger issue that we need to address before v1.0

now that @natemoo-re added a “framework selector” to create-Astro, we do have a better story to consider moving all built in renderers out of Astro

[matthewp]

@FredKSchott Thanks, I think you're saying you're against (3) which I am as well. Which leaves either (1), (2), or another option that hasn't been brought up yet. What do you think?

[natemoo-re]

now that @natemoo-re added a “framework selector” to create-Astro, we do have a better story to consider moving all built in renderers out of Astro

Yep, this was the goal of that change!

IMO I'd go with (2). The Lit renderer is worth moving into the monorepo and adding to the create-astro selector but we shouldn't enable it by default.

I'm actually +1 on removing any renderers from being included by default, but that's probably a conversation to continue elsewhere. Perhaps we could spin that and "the version problem" into new issues.

[FredKSchott]

Ah yea sorry, should have been more clear: strong +1 for option 2