How is melpa built?

[ayys]

How is melpa built?

[jcs090218]

I'm not the MELPA maintainer, but I will try to answer your question based on my knowledge.

is it a private server somewhere?

Yes, it can be a file server. I guess they are using Nginx since there are Nginx configuration files in this repo.

Are there specific Emacs versions or configurations used during the package build process to ensure compatibility?

No, package authors/maintainers are responsible for this.

How do package metrics get collected? (total downloads, number of packages, list of package dependencies)

See #481.

How is it being deployed?

I don't know how MELPA is being deployed, so I can't answer those questions. Perhaps, you may take a look at the my ELPA — JCS-ELPA. It's built using github-elpa and uses GitHub Page for its server.

[milkypostman]

Can you say more about what you're trying to understand? For what purpose etc.?

Most things we try to keep simple and don't have a ton of automation to just deploy stuff.

[ayys]

@milkypostman thanks for the response. I am researching alternative deployment strategies for Melpa. One of the ways is by moving the build+deployment process to github actions. The cronjobs can be moved to github as well with schedule-triggered actions .

Depending on what we are using to store the packages, we can maybe move that to something that runs https://github.com/halverneus/static-file-server. I am still thinking this through, but the goal is to make ready a proposal for a more transparent way to build and deploy Melpa.
I am very willing to put in my time to work on making Melpa deployments more transparent.

[purcell]

The code for all of this, including metrics and periodic rebuilds etc., is right here in the repo: there's a docker-compose config and all the necessary scripts.

So I don't know that any transparency is lacking here.

The docker config in this repo is a little short of being able to spin up everything conveniently on a different blank machine, because it assumes some things about the host machine, but documenting that and making it portable would be a good goal.

I don't think we'd be terribly interested in changing from our well-tested and reliable setup to alternatives without compelling reasons, because it involves work for us too, but feel free to share ideas or thoughts.

[tarsius]

For testing things locally you might find the "[TMP] ..." commits on master...snapshot-channel useful.