Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Packaging meta-ticket #18

Open
4 tasks
perrygeo opened this issue Dec 10, 2015 · 7 comments
Open
4 tasks

Packaging meta-ticket #18

perrygeo opened this issue Dec 10, 2015 · 7 comments

Comments

@perrygeo
Copy link
Contributor

A starting point for talking about how we're going to package and distribute this thing.

@tmcw mentioned that homebrew and apt-get should be the two primary targets.

I'd add that packaging a windows installer would really expand the potential audience. Whether it's worth the added maintenance burden (I don't even have access to a windows computer at the moment) is debatable.

  • identify target platforms
  • identify contributors with experience in those packaging systems
  • ...
  • everyone in the world has access to a one-line/one-click installer for command line access to Mapbox APIs
@perrygeo
Copy link
Contributor Author

perrygeo commented Feb 1, 2016

Global installation via sudo pip is really discouraged in the python world, yet we don't have any other way to install this globally. Using virtualenvs to create isolated environments is OK for python devs but is not a viable option for all end users. So I'd like to move on creating a homebrew formula sooner than later to at least get OS X users into the fray without much hassle.

Some decision points

  1. Should we just maintain our own tap (really just a repo with a Ruby formula in it) or try to work with the Homebrew team to get mapbox included in the homebrew repo? The advantage to a Tap is greater independence and lightweight publishing and maintenance (just git push). The advantage to the main homebrew repo is easier discoverability, tighter quality control and slightly less typing to install (brew install mapbox versus brew install mapbox/repo/mapbox). For now, I am leaning heavily towards using the Tap method until we work out the kinks.
  2. If we go the Tap route, what should our repo name be? We already have a mapbox/homebrew-custom repo (making the installation command brew install mapbox/custom/mapbox) but we might consider starting another homebrew-____ repo for this and other "official" Mapbox apps.

Besides that, I've read through the Python for Formula Authors docs and have a solid working formula ready to go once we decide on these details.

/cc @sgillies @tmcw

@perrygeo
Copy link
Contributor Author

perrygeo commented Feb 8, 2016

@tmcw @sgillies : what about a mapbox/homebrew-cli repo for this and other supported command line tools? This would make the installation command

brew install mapbox/cli/mapbox

Has a nice ring to it, would you agree?

@sgillies
Copy link
Contributor

sgillies commented Feb 8, 2016

@perrygeo or maybe just mapbox/homebrew and have just about any Mapbox project that's not in the main Homebrew repo (like Tippecanoe)?

@perrygeo
Copy link
Contributor Author

perrygeo commented Feb 8, 2016

@sgillies the repo name has special importance to homebrew's tap system - it assumes that you've got homebrew-<name> as the repo name and will install with brew install <username>/<name>/<formula> - a bit odd and it forces you to be more descriptive.

@perrygeo
Copy link
Contributor Author

perrygeo commented Feb 8, 2016

We could just name it homebrew-mapbox making the command sound like an incantation

brew install mapbox/mapbox/mapbox

tumblr_mjgybbewtf1r6lsuko1_500

@perrygeo
Copy link
Contributor Author

I just went ahead with homebrew-cli as the working repo: https://github.com/mapbox/homebrew-cli

We can adjust later if needed.

@perrygeo
Copy link
Contributor Author

perrygeo commented Jan 9, 2017

Another option to consider (though a bit on the experimental side) would be to transpile the Python code to Go using Google's Grumpy. This could produce static binaries on all our target platforms. In theory.

@sgillies sgillies removed this from the 1.0 milestone Jan 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants