This application would pretty much work like npm, yum, apt-get, brew, composer, etc., except that we're going to build the whole thing ourselves from scratch.
Great ideas:
- yuck
- phew
- comphoser
- phackage
Description
Description
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Resolved | epriestley | T8116 Prototype a package management application | ||
| Resolved | epriestley | T8117 Choose the most straightforward possible name for a package management application |
Event Timeline
Comment Actions
- aphm (Another Phackage Manager)
- ppp (Phabricator Package Provider)
- Ekstand (Pivoting the regular naming convention?)
Comment Actions
Amazing ideas follow
- phax - some sort of phabricator box plus its like fax which is vaguely applicable
- phundle - you know, a fun bundle
- pharcel - just a letter away from parcel
- phode - phabricator + code mashed up yields this gross sounding word
Comment Actions
- ppm is already taken :-(
- phump: I tried to figure out how many consecutive ps I could string together and started making a sound like this
- pkg Somehow not taken yet, hurry!
Comment Actions
whoops posted these in the wrong task:
Phrame? (frame)
Phramework?
Interphusion?
Phreight? (freight)
I think I got some good ones in there :P
Comment Actions
arcanist has nice arc command...
so maybe go for "Phundle" and have command phun ?
Generally I like phundle best.
Other I could come up with sound... eh: apt-get: pha-get (try saying that out loud in office, I dare You).
Comment Actions
I think we aren't actually going to have a standalone binary for this (i.e., the CLI will just be arc install, etc., with a possible bin/whatever standalone in Phabricator that doesn't need namespacing) so I suppose we can just call it "Packages".
This conflates a little with Owners but maybe we could rename the Owners objects to "Claims", which I think has a reasonable ring to it.
Comment Actions
It's definitely little uncool, but not needing a binary makes it a bit less relevant.
I think this will also probably be an application that new users interact with (e.g., new hires installing stuff) but don't actually use meaningfully (e.g., they're not publishing anything to it) and which doesn't have third-party alternatives, so that tends to increase the costs (new user cognative load) and decrease the benefits (disambiguation, googleability) of having a more unique name, at least a bit.
None of the suggestions on this task seemed that amazing, either. We can still change it before it unprototypes if anyone comes up with something amazing.