Re: Adding a readme to the pgarchives repo

On Mon, 16 Jun 2025 at 13:26, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> The change in schema.sql to add subscriber_access should surely be a separate commit, it's not part of adding a README file. (in fact, many thing are not adding a README file). So I'll separate thato ne out right away.

Makes sense. To be clear, the README + other changes I proposed is
mainly born out of trying to get this system running without any info
on how to do so. So reverse engineered some steps to get a
semi-functioning setup. I spent quite some effort trying to get
something usable working locally. So it seemed good to have that at
least as an example for other people to start from. Even if there's
probably some missing/weird/suboptimal stuff in there.

>That said, this one is also caught in the limbo between some things being as migrations and some things not, that reall needs to get cleaned up :/ Celestin worked on that at some point, I think, and I need to get back to properly reviewing that.

That sounds nice. I was unable to figure out why it was split like
this, so I chose to change the schema.sql file, because it seemed much
more complete.

> I'm not sure how much sense it makes to load data from schema.sql. Wouldn't it be better with a dev_data entr?

Done

> Also, I don't think removing text search configuration completely from a dev install is the right way to go. All of this is definitely part of the system and if nothing else one would want to make not to accidentally *break* it in dev, thus they are needed.

Added setup instructions now for those. I didn't before because it was
quite hard to reverse engineer how to set this up and it wasn't
necessary to get the API working. They work for me i.e. I can search.
But feel free to change them if you think they are incorrect.

> The example settings file I think would also need the CSRF_COOKIE_SECURE and SESSION_COOKIE_SECURE flags, no?

I didn't hit problems with this during my testing, but seems reasonable yes.

> The comment for PUBLIC_ARCHIVES is incorrect, as it's not just about the API, it's about access to the archives at all.

Changed

> Why is uwsgi in requirements.txt and not in the apt-get install prerequisite? That would make it much easier :) (same thing would go for the other requirements added of course, but those do make more sense to keep around)

Seemed nice to not pollute people their globally installed tools
unnecessarily. Also, less cross-platform stuff to worry about, since
not every-one is developing on a debian based system.

> And if one follows the instructions, the whole run_dev script shouldn't be needed at all since you now the virtual env is installed in env?

Sadly the run_dev script is needed, because we need to provide the
path to the django admin static files. That path includes the python
version number even in the venv... And the python version obviously
differs across systems.

> And finally why do we need to comment out things in the sample file? it's just a sample file after all?

The main reason is so that this file can simply be cp-ed to
`archives.ini` and the system will work (although without the
commented out features). I ran into this because the varnish purgeurl
made load_message.py get stuck, I assume because the default URL is
firewalled.