duojs / package Goto Github PK

Should we continue supporting 0.10? Or is it time to move onto 0.12 and iojs?

Since we're not caching branches like master, we're fetching these packages twice.

Hey! I think it is really great how you have broken duo up. I have just finished describing a project that will make heavy use of duo-package. If all goes well it should offer an opportunity to help build up this project up over time.

https://github.com/codingcoop/pollinate

The idea may seem a little abstract... Our focus is to revolve it around virtualization and automation, but it is distilled to be used creatively. If you were curious, feedback is very welcome :)

just fetch instead, that way we won't resolve branches for no reason.

can probably just be done synchronously as the module loads.

Getting stuff like this on pull requests: https://travis-ci.org/segmentio/analytics.js-integrations/builds/37686296#L133

my vote is that duo should check for GH_TOKEN, if it's not there just use the without a token...

Package('visionmedia/jade').fetch(fn)

will fail for example.

right now, inflight isn't up-to-date. This causes issues when you make local modifications and then re-run the same instance (like for duo-watch)

also, checking if the package already exists in the directory was removed, maybe by accident, maybe to fix something, i don't remember.

@juliangruber's spec.

got this in travis ci:

we need better errors too, like show on which repo it failed etc..
:/

i feel like we've tried to avoid this in the past so people are able to share their logs without giving away potentially sensitive information...

$ DEBUG=* make
[ ... ]
  duo-package [email protected]: fetching from https://{TOKEN}@github.com/visionmedia/debug/archive/2.1.3.tar.gz +1ms
  duo-package curl -v -L -H "User-Agent: duo-package" https://{TOKEN}@github.com/visionmedia/debug/archive/2.1.3.tar.gz +2ms
[ ... ]

looks like this package can't install stuff like component/[email protected], yields/[email protected] since github uses pagination.

i wrote a tiny module to solve this, not sure if we should add it here or https://github.com/matthewmueller/gh, let me know where you want it and i can pr :)

github api issue, not sure what to do about it without major hax.

why do we do this when we've got a Package#token() method that we call from within Duo#package()?

imo, duo(1) should be only place your ~/.netrc is read, and it should just pipe that data all the way to gh-resolve.

As per: duojs/duo#258 (comment)

per duojs/duo#116.

this will allow us to abstract all of the api stuff (arguably the most complex part of the codebase), letting this module just handle the important stuff like untarring, caching, installing, etc. it'll also allow us to easily add support for other providers (bitbucket, gitorious, etc.).

public api needs to be decided, but something based on duojs/duo#116 (comment) has my vote:

var pkg = new Package('somebody/something', '0.13.x')
pkg.provider(require('duo-github'))
pkg.token('abcdefg')
pkg.directory('components')
pkg.fetch(function(err){ ... })

var pkg = new Package('someone-else/somerepo', '~0.1')
pkg.provider(require('duo-bitbucket'))
...

var pkg = new Package('someguy/somepackage', '~0.1')
pkg.provider(require('duo-gitorious'))
...

in order to not break back-compat, we could simply add something like:

if (!this.provider()) this.provider(require('duo-github'));

to Package#fetch.

check headers if content-type doesn't make sense simply abort and throw a descriptive error with the repo name.

Looks like there may be a type at line 101?

/Users/evelo/Documents/Repos/pollinate/node_modules/duo-package/lib/index.js:101
Package.cleanCache = function *() {
                              ^
SyntaxError: Unexpected token *
    at Module._compile (module.js:439:25)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)
    at Object.<anonymous> (/Users/evelo/Documents/Repos/pollinate/lib/fetch.js:10:15)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)

connection is super flaky in india, would be great to print out something nice, instead of hanging.

this can throw an uncatchable exception after the first tick. any reason we're not just doing fs.mkdirSync(...)?

I think the cache should be a in a place that naturally has an "expiration". I think require('os').tmpdir() is a good place for this. I'd also like to keep $HOME clean

Also, duo shouldn't complain if it can't find the cache. Running into this error:

$ duo entry.js

  Error: ENOENT, open '/Users/matt/.duo/[email protected]'