Sure you can front static assets with the free Cloudflare tier...
[a] which is fine if you're happy with the inflexibility that free Cloudflare offers. And you live in a country where the free tier doesn't have horrible routing (eg use the Sydney AWS region, put Cloudflare in front of it and then watch your traffic to/from Sydney take a round trip via the US or Singapore)
[b] every single AWS service charges egress fees (ie Cloudfront doesn't help at all)
No, but you're not the OP above my comment, so my question still stands.
> (eg use the Sydney AWS region, put Cloudflare in front of it and then watch your traffic to/from Sydney take a round trip via the US or Singapore)
I don't understand? I don't have this issue (I'm in Brisbane; I use ap-southeast-2)
> [c] this does nothing for non-static assets
Non-static assets are going to be very tiny in most cases, and the problem then becomes about volume. If you've got volume and your business model doesn't suck, then you can afford the rate (my understanding is AWS' network egress charges are gross compared to other vendors.)
You can do others (eg West Coast US, Japan, Australia -- it's all just AWS regions under the hood) but to do that you have to be in a 'private space' which is effectively a dedicated clone of the Heroku management infrastructure.
If you were paying a few hundred dollars per month you're now going to be paying a few thousand. IMO Heroku is shooting itself in the foot with this price structure.
nginx buildpack + python buildpack == nginx to serve static content and gunicorn for the python backend. Of course you now have to know how to set up an nginx config file so it does take away somewhat from the "just works" simplicity of Heroku.
Although even whitenoise is still ok if you're going to set it up with a CDN as the frontend for your static assets. If you want simplicity then you do it using one of the CDN addons.
Whitenoise is not a limitation of the heroku platform, it's really a symptom of suboptimal documentation.
It seems that it was somewhat inevitable given the US vs Australian distinction on whether to protect Creativity vs Effort (years ago I investigated this rabbit hole when I had a client who wanted to set up a White Pages clone site by buying the data from someone who had digitised it [with a lot of manual entry!] by low-paid Indians. They were very disappointed when I told them to contact an IP lawyer because it was almost certainly going to get them sued)
I did cry a little at the court's assertion creating the huffman table required "a very great deal of hard work". Gather a corpus of databases you have lying around, count the occurrences of each byte value and apply a <50 line algorithm that has been around since the 1950s and is a pretty standard university assignment. "a very great deal of hard work" indeed.
Presumably division 4A / s47D would now allow the cloning of the data table if decided today -- are you aware of any post-1999 case law?
- until a few months ago no way to sync an environment with a lockfile (remove packages that shouldn't be there)
- no way to check if the lock file is up to date with the toml file
- no way to install packages from source if the version number is calculated (this will likely never be fixed as it's a design decision to use static package metadata insetad of setup.py, but is an incompatibility with pip)
- no way to have handle multiple environments: you get dependencies and dev-dependencies and that's it. You can fake it with extras, but it's a hack
- if you upgrade to a new python minor version you also have to upgrade to the latest poetry version or things just fail (Something to do with the correct selection of vendored dependencies. May have since been fixed -- new python versions don't come out all that often for me to run into it. And in fairness the latest pip is typically bundled with each python so it avoids that issue)
I still use poetry because it's more standard than hand-rolled pip freeze wrapper scripts, and there's definitely progress (the inability to sync packages was a hard requirement for me but is not fixed) but it's not quite there yet
Interesting, i usually rebuild my env from pacakges so don't notice 1,2, or 3. I guess 2 should be fixable by poetry by including more from the toml in the lock file. Point 4 also didn't bother me as I in general just have the main and dev deps, this seems an easier thing to fix for poetry though. I actually have encountered 5 when fiddling around with pyenv.
If it wasn't so opinionated it might have been more successful.
Just one example: you want your virtualenvs to be created in ~/.virtualenvs so that pipenv is a drop-in replacement for virtualenvwrapper+pip? Tough luck for you, Kenneth Reitz doesn't think that's how it should be done.
At least 3 or 4 times some issue I've wanted resolved I found in the issue tracker with the last message "we'll have to check with kennethreitz42 whether we're allowed to change that" and then silence for a year.
It could still catch up with poetry, but from what I've seen there's a fundamental mindset difference in how change requests are approached between pipenv and poetry.
