astro
astro copied to clipboard
Django 2.2 needs mysqlclient >= 1.3.13
Hello! Django 2.2 requires mysqlclient>=1.3.13
per this commit. lambda-packages
currently offers mysqlclient
at 1.3.12. I'd like to raise the issue and request an upgrade.
Django 2.2 was released earlier today — presumably, not on an April Fool's basis 😅— and has been designated a Long Term Support release, which will receive security updates for at least three years into the future, so I think it's worth the effort.
Compiling it myself is a bit outside of my typical wheelhouse, so I'm happy to defer to others :D but otherwise, I'll take a crack at it this evening
( Not clear to me, also, if there might be other work necessary to get this update into Zappa. )
There is a pull request related to this: #95
Unless this library is being retired, this issue really should be addressed pretty quick.
See also #97 #95 #100
Thanks! This is a legit bug I think. I can take a look as I'm currently in the middle of working on build stuff.
Ok, I've had some time to think about this and I don't think it's a bug, but it is definitely an interesting discussion. As you said, I could see people wanting to have files in their astro/ folder and reference them as being relative to the currently astro page's file. But at the same time, people will definitely want to reference relative to the current page URL.
I'd like to hold off on doing anything on this for now and see what other people think; if any sort of pattern emerges out of this. For example, I could see an argument for considering images inside of the astro/ folder as being processed differently, like perhaps they would be base64 inlined in this case.
I think the best way to experiment with these ideas for now is to create a custom component that encapsulates this idea. For example you might have:
<Image src="./social.png" inlined />
Where the Image component makes this internally referenced to the astro folder and in this case inlines the image.
Ok, I've had some time to think about this and I don't think it's a bug, but it is definitely an interesting discussion.
I did make some changes to how files within the Astro folder (now src/
) were resolved, and this should be either fixed or at least possible now, even with collections and dynamically-generated pages. Every file in src/
should now be represented 1:1 in the final /_astro/
output folder, so we should just handle this for users.
While I think public/
is a good pattern, it can also become messy having only one place to put static assets. I’d like to let the user decide what’s best for them, and sometimes having assets live alongside pages is more beneficial.
We are tracking a fix for this in this RFC: #310, so closing this one.