Add gdal

[lucasnoah]

Add GDAL 2.0.0 as a package. I made it on an amazon-linux instance. No build.sh file was created, but it did not seem necessary when looking at other examples.

[Miserlou]

Because the package is too large to work on AWS lambda, I can't merge this in quite yet.

The files are unstripped though, can you try recompiling and stripping or maybe using objdump to strip the existing artifacts, if that works?

[Miserlou]

Bump! Gotta few spare cycles to try to trim those files?

We just added PyProj, so geo support in l-p is improving!

[ojongerius]

This would take care of (at least a part of) https://github.com/Miserlou/lambda-packages/issues/12, right?

[hammadzz]

I am new to Zappa but I really need this package as part of my app. How can I help get this fixed for a merge? Its been a long time since it was opened

[giovannicimolin]

Any news on this yet?

[FredKSchott]

Really appreciate how thought-through this is! Some thoughts:

Inlining

• bikesheddy: <style inline> vs. <style critical>?
• less bikesheddy: Should it really be the component user / composer who dictates if CSS is critical? I would love to explore some alternative designs here. For example:

// using config
criticalCss: ['./components/Hero.hmx', ...]

// using <script astro> (pages only)
<script astro>
  import Hero from '../components/Hero.hmx';
  export function setup({criticalCss}) {
    criticalCss([Hero, ...]);
  }
</script>

// using the component
<Hero css:inline />

// using some super out-there new syntax
<astro:inline component={Hero} />

Importing

• I don't think I 100% grok the distinction between Astro's @use support and Sass, but I think anything other than "if you want @use, use lang="sass"" would become very difficult to document, explain, and understand. "Oh, you're using @use! Wait, is it Css @use or Sass @use? Yes, I know you couldn't find documentation for Css @use, that's because..."
• Remember that you can rely on an optimization step to optimize the CSS for the final production build. I'm coming around to doing more bundling on our end as a part of building, outside of optimization. But, something like "bundle these otherwise totally valid @imports" is a perfect use-case for work to push off to the generic optimize step. Basically, I would push for this being valid ouput of our Astro build:

/* components/Hero.hmx */
@import '/foo.css';
@import '/bar.css';
/* ... (hero styles) */

/* components/Banner.hmx */
@import '/baz.css';
/* ... (banner styles) */

Dynamic components

• Yeaaaaaa that's an interesting problem, isn't it.
• It would be great if we could get away with: ":dynamic is all about dynamic JS, but the CSS has already been bundled into the head." But can we? I can't help but feel like getting rid of all CSS loading concerns/complexity in dynamic components on the page would be AMAZING. Like, a valuable feature in its own right.

[drwpow]

<style inline> vs. <style critical>

🤷🏻 I’m open to either! Will think about it

---

// using config
criticalCss: ['./components/Hero.hmx', ...]

❤️ This is a really cool idea. I think it’d take some experimentation, and couldn’t be global, because the whole idea of critical CSS is only style things above the fold which would be page-specific, not component specific (🤔 should there be page-level config? routes? maybe!). But that said, I love the idea of making it more automatic.

I do want to err on the side of the user having control, because if we inline too much it quickly becomes a counter-productive effect of being worse than a giant .css file. But to your point, putting it 100% on the developer is hard, and is the reason more people don’t take advantage of it.

---

I don't think I 100% grok the distinction between Astro's @use support and Sass … But, something like "bundle these otherwise totally valid @imports" is a perfect use-case for work to push off to the generic optimize step.

That’s fair. I’m not a big fan of @use, it’s just a hedge to give the user control. Put another way, imagine a scenario where a user wanted to not bundle the @import statements. Or they wanted to bundle some (local styles), but for other requests leave the @imports fetching remote files (npm CSS). I wanted to give a user more control:

• @import works exactly like CSS. We will never hijack this.
• @use (or pretend it’s @bundle or something else) is made up (not CSS spec): only use this if you want a certain thing to happen.
• Sass explicitly moved away from hijacking CSS’ @import because there were a lot of headaches around implementing a spec feature…not to spec. I think there is a good warning there about not changing core language features (an example being print styles which require @import)

Lastly, I don’t know if we can use Snowpack’s optimize step for this. I think Snowpack optimize is currently scoped to using optimize: { bundle: true } which relies on esbuild + specifying entrypoints, right? And I don’t think that currently bundles @import statements; so even if we did use that we’d have to change Snowpack behavior.

How do you feel about improving Snowpack’s optimization vs just doing it in Astro for now?

[drwpow]

It would be great if we could get away with: ":dynamic is all about dynamic JS, but the CSS has already been bundled into the head." But can we? I can't help but feel like getting rid of all CSS loading concerns/complexity in dynamic components on the page would be AMAZING. Like, a valuable feature in its own right.

I think we can, at least for now. Drew’s opinion: bundling and webpack have been great for JS dev, but they’ve really set us back in terms of efficient style loading. It’s always been second-citizen, and been a turnoff for the CSS folks (Filament Group, et al).

I know that the “include dynamic CSS in head and JS loads later” isn’t a perfect performance story. But I think it’s loads better than “webpack’s default.” And the alternative gets into a JS runtime to inject styles. So I’m not saying this is the ultimate form, but IMO I think it’s a pretty good first cut! And obviously we can put it through its paces to test its limits.

I agree though that getting that right is a feature in and of itself, and an achievement within our reach! So I agree: let’s do this! But I would like to give that dedicated time and attention, after the initial release.

[FredKSchott]

the whole idea of critical CSS is only style things above the fold which would be page-specific, not component specific (🤔 should there be page-level config? routes? maybe!)

To clarify I meant criticalCss as some astro.config.js value, but I think you saw it as some return value from the setup() function which actually makes a lot more sense. It could also use the components directly:

// using <script astro> (pages only)
<script astro>
  import Hero from '../components/Hero.hmx';
  export function setup() {
    return {
      critical: [Hero]
  }
</script>

[FredKSchott]

Shared this in a message to you, but sharing here also: https://esbuild.github.io/content-types/#css

Since snowpack uses esbuild behind the scenes, we should be getting @import bundling by default when you go to optimize your final build. I think that gets you the behavior you were looking for, but some experimentation still needed.

[eyelidlessness]

Dynamic components should probably work the same way as SSR components—include in bundle? On the fence about this

I'm too new to Astro to have a solution in mind, but I do want to express that this can be a pain point when hydrating components in Microsite. I'm using Fela on my personal site and csstag on a client project, and in both cases it can be difficult to get the dependency tree right to avoid bundling otherwise static styling (and the library dependencies!).

[drwpow]

in both cases it can be difficult to get the dependency tree right to avoid bundling otherwise static styling

Right! There‘s no universal answer that’s best for everybody. In general I think a good practice is to try and not load heavy styling libraries from a component; if something is very weighty then try and include it in your global bundle so it’s cached and globally-available. We’ll try and outline best practices in the future, and we‘ll try and walk that delicate balance between bundle most things but not everything, vs load things on-demand but not everything, either.

[drwpow]

Thanks all for the input! There will be plenty of room for more input going forward. But we at least have a starting point now.