Source code for https://cargofox.io/
Make the upload bash script not upload your entire home dir
cadd2da444bf — Simon Heath 4 years ago
Set license to GPLv3.
Working on article metadata and list page.

heads

tip
browse log

clone

read-only
https://hg.sr.ht/~icefox/cargofox
read/write
ssh://hg@hg.sr.ht/~icefox/cargofox

#Setup

Repo: https://hg.sr.ht/~icefox/cargofox

Issue tracker: https://todo.sr.ht/~icefox/cf_issues

Installing dependencies:

# Install rustup using rustup.rs
browser https://rustup.rs/

# Install `rust` and setup beta, for now (will be stable soon)
# Install postgres
sudo apt install postgres libpq-dev

Initial database setup

# Create database:
sudo -u postgres psql -c "CREATE DATABASE cf_test;"

# Create user
sudo -u postgres psql cf_test -c "CREATE USER cf_testuser WITH PASSWORD 'testpassword';"

# Add DB URL to `.env` file
# You may have to add a port to the postgres URL, idk
echo 'DATABASE_URL=postgres://cf_testuser:testpassword@localhost/cf_test' > .env

# Create shared data dir
sudo mkdir -p /var/lib/cargofox
sudo chown -R icefox:icefox /var/lib/cargofox
echo 'DATA_DIR=/var/lib/cargofox/' >> .env

# Install diesel helper tool.
sudo apt install libsqlite3-dev libmariadb-dev-compat
cargo install diesel_cli

# Run migrations
diesel migration run

# Run unit tests
cargo test

#.env config

Environment variables, and their defaults.

All environment variables can be put in an .env file. There are no defaults, they must ALL be specified. Every time I've put a default in the program I've had it inconveniently do the Wrong Thing at some point and I've needed to specify something sensible anyway. :|

DATABASE_URL=no default
DATA_DIR=no default
OUTPUT_DIR=no default

#To do next:

  • Make the index links alphabetical
  • Put neat summary statistics on front page
  • Add better unit tests...?
  • Go through and remove TODO and BUGGO's
  • Crack open crates and do basic stuff: tokei, build.rs presence
  • List crate feature flags
  • Fix dependency bugs
  • Start thinking how to build crates. Docker, VM's, whatev's. If we want to try to build on Windows then VM's might be the way to go anyway.
  • At SOME point we want to have a staging site, and like, have the staging and real sites run off different branches of this repo or something. Then we can have a cron job running the live site.
  • Make a thing that saves the names of crates with download problems and omits those on the next run.

#Things not implemented yet

  • In crates index: Version::features() is incomplete, Dependency::features() is not implemented

#Things to analyze

  • ez: does the crate's file actually match its checksum?
  • How long it takes a heckin' crate to build. I'm looking at YOU, unicode-normalization.
  • How long it takes to build vs. number of lines.
  • Are there duplicate or near-duplicate crates in existance?
  • Do analysis on dependencies -- depth, breadth, think of other stuff
  • Summary statistics: Rate of new crates, total lines of Rust code (and docs), rate new code is being written...

#Bugs

  • Tokei analyses don't get cleared on each analysis run, but just added on to? There's a note in the DB migration stuff about adding a unique constraint there.

#Notes

#Crate crates

Code highlighting:

  • syntect

SASS:

  • sass-rs
  • rsass (maybe)

#Things to examine

As https://www.reddit.com/r/rust/comments/ai7640/whats_everyone_working_on_this_week_42019/eepqa3i/ says: Have you thought about creating a bounties system for the top issues so that people who rely on those crates could easily identify problems and incentivize the community (or crate maintainers) to work on them? Maybe something like GitCoin or BountiesNetwork? https://gitcoin.co/ https://bounties.network/

#Particular thanks to

  • cargo_metadata
  • tokei
  • crev
  • diesel
  • askama
  • rayon
  • semver
  • pbr

For most of you, it wouldn't be possible to do this without you. For some, you just solved a very specific, not terribly simple problem and did it extremely well.