#57 data_basedir in mediagoblin.ini is not updating defaults in config_spec.ini 7 days ago

Comment by ~sturm on ~mediagoblin/mediagoblin

Thanks for your packaging efforts!

MEDIAGOBLIN_CONFIG is only used by the Celery task queuing process, not by the MediaGoblin web application. Your options here are:

a. Specify your config file in paste.ini and run the web application with paster serve paste.ini as per our traditional deployment approach (see https://docs.mediagoblin.org/en/master/siteadmin/deploying.html#run-mediagoblin-as-a-system-service). You'll still need MEDIAGOBLIN_CONFIG for running celery worker. Sorry for the inconsistency here.

b. Use the new gmg -cf CONF_FILE serve and gmg -cf CONF_FILE celery commands. These should be good to go, but we haven't switched our documentation over to use them yet, so haven't been as thoroughly tested.

For what it's worth, it may be useful to check out my work-in-progress Guix package. The inputs section may be relevant to your work. I'm not using the project's make, but rather installing as a Python package: https://git.sr.ht/~mediagoblin/mediagoblin/tree/master/item/.guix/modules/mediagoblin-package.scm

#56 Left-right arrow shortcut keys surprising 3 months ago

Ticket created by ~sturm on ~mediagoblin/mediagoblin

In the age of online video, the left and right arrows typically skip forwards and backwards in a video. In MediaGoblin, they skip to the next item, so if you're watching a video that will stop and instead show the next/previous media item, perhaps another video.

We probably should drop these shortcuts.

#55 Consider switching out waitress? 3 months ago

Ticket created by ~sturm on ~mediagoblin/mediagoblin

We've had a user on IRC having trouble with large file uploads. Turns out waitress has its own internal max file upload max_request_body_size which defaults to 1G.

Waitress seems a bit less commonly used than other WSGI servers. I've had professional experience with gunicorn and uWSGI, but not waitress. All application servers have their own quirks, but I wonder whether gunicorn might be a better choice, simply because it's fairly commonly used.

#54 Deployment: avoid extra "mediagoblin" user 3 months ago

Ticket created by ~sturm on ~mediagoblin/mediagoblin

I ran through the deployment guide last night and frankly, it's complicated. I think we need to do everything we can to simplify the first install experience, but give people the tools to scale if needed.

(Docker is one way to simplify this, but I'd also like to support the traditional install too.)

The guide recommends creating a "mediagoblin" user account to run the application under. I've personally always run MediaGoblin with the default "www-data" user created by installing Nginx on Debian/Ubuntu. I'd suggest we move the separate user creation to the "Further considerations for production deployment" page (along with PostgreSQL).

#53 Install docs use "stable" branch, but upgrade docs use specific tag (inconsistent) 3 months ago

Ticket created by ~sturm on ~mediagoblin/mediagoblin

We should either use the branch ref in both cases, or the tag ref in both cases. See docs/source/siteadmin/deploying.rst (branch) and upgrading.rst (tag).

#52 Separate the source checkout from the install/run 3 months ago

Comment by ~sturm on ~mediagoblin/mediagoblin

What brought this issue up for me is that currently someone installing from our deployment docs gets whatever version is in the "stable" branch, which quite likely isn't an explicit release, just whatever git commit happened to be there at the time.

On the other hand, it means we can just push changes to "stable" and anyone installing will get the latest version without us having to make an explicit release.

#52 Separate the source checkout from the install/run 3 months ago

Ticket created by ~sturm on ~mediagoblin/mediagoblin

Until now MediaGoblin has generally been run from a git source checkout. That's useful for developers, but it doesn't align well with OS-packaging, which has strong separation between the build, install and run phases - often done at different times, in different contexts and by different people.

With OS-packaging there is typically some sort of built distribution asset/package that doesn't require arbitrary internet access other than for the package manager to download the package and any dependency packages.

I don't know that I fully have my head wrapped around the issues and implications here, but my intuition is that the discipline imposed by the OS-packaging requirements is probably going to be good for us.

Being interpreted, Python does blur the typical build/install/run lines. Why shouldn't you be able to modify the source directly if you want to, without having an explicit build/install step if it's not required. That's certainly widely done in PHP and in professional deployment of Python web applications.

We certainly want MediaGoblin installation to be simpler than it is currently - at present you need significant technical experience to install and maintain it.

#43 Move virtualenv to a subdirectory 3 months ago

Comment by ~sturm on ~mediagoblin/mediagoblin

~shtrom has made progress towards this in the build/Docker improvements we've just merged, but after discussion we realised that we need to be careful to minimise the impact on anyone upgrading an existing install.

#36 Build refactoring with docker support 3 months ago

Comment by ~sturm on ~mediagoblin/mediagoblin

These configure, build and Docker changes have now been merged into master. Thanks for your work here ~shtrom!

REPORTED RESOLVED IMPLEMENTED

#14 Are ./configure && make appropriate for MediaGoblin? 3 months ago

Comment by ~sturm on ~mediagoblin/mediagoblin

pdf.js can be put into bower.json. That's one less submodule.

Just wanted to note that ~shtrom looked at this and it's a little more complicated than on first glance. We cannot use pdfjs-dist at the moment because the viewer.html that we rely on is not included. See https://github.com/mozilla/pdf.js/issues/5609.