<paroneayea> kuno: around?                                              [14:07]
<kuno> yes                                                              [14:10]
<paroneayea> kuno: you're the one who, in conversation about packaging and
             etc, expressed "but I like git checkouts for deployment, because
             complete and corresponding source!" right? :)
<kuno> yes!
<paroneayea> kuno: great!  because I have a C&CS puzzle and I want to talk to
             you about my suggested solution.                           [14:11]
<kuno> and I love puzzles!
<paroneayea> kuno: like many web development projects, mediagoblin follows the
             really bad practice of "just check the javascript libraries into
             the source tree"
<paroneayea> kuno: this is bad for a variety of reasons.  Reason 1 is that it
             bloats the source tree, obv                                [14:12]
* kuno nods
<paroneayea> Reason 2 is it's usually a byte-compiled version of the
             project... actually proprietary if you aren't doing the C&CS side
             of things when you think about it!
<paroneayea> it's "standard practice" for webdev, but bad practice.
<paroneayea> kuno: the problem is made worse though, because most javascript
             libraries today aren't just "unpack and run" anymore       [14:13]
<paroneayea> lots of them count on node.js to compile                   [14:14]
<paroneayea> an onerous requirement for someone doing drive-by contributions!
             Or really any contributor.
<paroneayea> kuno: so here's my thought on a solution, let's see what you
             think.
<kuno> I disagree on the onerous requirement part, but otherwise agree with
       your premise.
<paroneayea> kuno: so I am thinking maybe having a file like:
             http://pamrel.lu/48764/                                    [14:18]
<chaosgoblin> Title: Pamrel - 48764 (at pamrel.lu)
<paroneayea> and some python code
<paroneayea> that knows how to fetch and extract and move the binary version
             in to place                                                [14:19]
<kuno> paroneayea: I think i'd be crazy to ignore the npm and bower
       repositories
<kuno> s/i/it/
<paroneayea> but *at minimum* includes instructions on how to clone the
             repositories, but maybe even actually can build them
<paroneayea> with the c_and_cs part
<paroneayea> kuno: yes, those exist, but the problem is                 [14:20]
<paroneayea> users already have trouble with running into python's package
             manager with our stuff
<paroneayea> having them beat their head against 1000 unique package managers
<paroneayea> that's onerous :)
* paroneayea exaggerating of course, we don't have 1000 deps, but you get it
                                                                        [14:21]
*** pitanga (~rodrigo@fsf/member/pitanga) has quit: Read error: Connection
    reset by peer
*** pitanga (~rodrigo@fsf/member/pitanga) has joined channel #mediagoblin
                                                                        [14:22]
<paroneayea> kuno: at minimum, I think this is an improvement over things as
             they are
<paroneayea> but it could be much better.
<kuno> paroneayea: yeah.  I can see the argument that an end-user shouldn't
       need to have a javascript package manager installed to deploy
       mediagoblin, but then they also shouldn't need a python package manager
       really.  You should ship those folks the full thing, all packaged and
       ready to go.
<paroneayea> kuno: yeah.  I think the thing is, I want to hit all the major
             parts of the spectrum:
<paroneayea>  - just install the package and all packages via system packager
                                                                        [14:23]
<paroneayea>  - hack on mediagoblin version: mediagoblin's checkout, but then
             pull down prebuilt packages for the js deps and etc easy
<paroneayea>  - full C&CS auditor mode!  have at minimum the ability and full
             documentation on how to build the whole thing, top to bottom.
                                                                        [14:24]
<kuno> paroneayea: Implementing a half-hearted javascript package manager
       doesn't seem like a great solution.  If you want to stay within the
       python ecosystem, can you not just package your deps for fanstatic?
<paroneayea> "for fantastic"?
<paroneayea> kuno: you mean make python eggs? :P
<kuno> paroneayea: there's all these javascript libraries on pypi,
       https://pypi.python.org/pypi/js.jquery/1.9.1
<chaosgoblin> Title: js.jquery 1.9.1 : Python Package Index (at
              pypi.python.org)
<paroneayea> kuno: "yes you can" but it's really quite messy.           [14:25]
<paroneayea> and they aren't well maintained.
<paroneayea> I did that at one point with a job's deps
<paroneayea> it turned into a nightmare.
*** pitanga1 (~rodrigo@200-153-132-135.dsl.telesp.net.br) has joined channel
    #mediagoblin
<paroneayea> at the moment I just want something that untars things into a
             directory mostly
<paroneayea> since effectively that's what we have
<kuno> paroneayea: yeah, if you want well-maintained, you need to get these
       javascript packages from npm and bower :)
<paroneayea> right
<paroneayea> so this is intermediate land :)
<kuno> paroneayea: implementing a half-hearted javascript package manager
       which just pulls stuff from npm could be an option.  The package
       description files are straightforward, and I expect the npm API to be
       similarly so.                                                    [14:26]
*** pitanga1 (~rodrigo@200-153-132-135.dsl.telesp.net.br) has quit: Read
    error: Connection reset by peer
<paroneayea> kuno: maybe... but is probably a lot more work than just wget and
             untar.                                                     [14:27]
<paroneayea> while checking a hash
*** pitanga1 (~rodrigo@200-153-132-135.dsl.telesp.net.br) has joined channel
    #mediagoblin
<paroneayea> kuno: but!                                                 [14:29]
*** pitanga (~rodrigo@fsf/member/pitanga) has quit: Ping timeout: 246 seconds
<paroneayea> the thing I suggested above
<paroneayea> should be able to handle that.
<kuno> paroneayea: anyway, I need to get back to the dayjob.  I'm going to
       think about this problem a bit more.                             [14:30]
<paroneayea> kuno: ok :)
*** pitanga1 (~rodrigo@200-153-132-135.dsl.telesp.net.br) has quit: Read
    error: Connection reset by peer                                     [14:31]
<paroneayea> kuno: at the very least, I feel from the conversation we just had
             that the ~solution I'm putting forward is "adequate enough", if
             not great, but much better than existing check into git
             "solutions" ;)
*** pitanga (~rodrigo@fsf/member/pitanga) has joined channel #mediagoblin
*** pitanga1 (~rodrigo@200-153-132-135.dsl.telesp.net.br) has joined channel
    #mediagoblin                                                        [14:33]
*** pitanga (~rodrigo@fsf/member/pitanga) has quit: Ping timeout: 245 seconds
                                                                        [14:35]
<kuno> paroneayea: I guess my main issue with it is that you're duplicating
       metadata.  I love metadata, but for javascript the existing package
       managers already have all the metadata you need (link to git source,
       authors and license fields, etc...)                              [14:36]
*** pitanga1 (~rodrigo@200-153-132-135.dsl.telesp.net.br) has quit: Read
    error: Connection reset by peer
<paroneayea> kuno: well, in that sense                                  [14:46]
<paroneayea> the real thing is we should be using a unified package manager
<paroneayea> and in that sense also
<paroneayea> I think davexunit is right in that we should maybe all be using
             guix instead of virtualenv and etc ;)
<kuno> paroneayea: guix/nix do seem really promising.  I don't think end-users
       should have to deal with package managers though,..              [14:50]
<kuno> and for developers it seems perfectly OK to expect a python developer
       to have a python interpreter installed to run a package manager written
       in python
<kuno> and for a javascript developer to have javascript compiler or whatever
       installed to run a package manager written in javascript         [14:51]
<paroneayea> kuno: yep, but as you see
<paroneayea> the problem is when python developers need to run javascript
             compilers ;)                                               [14:52]
<paroneayea> and etc
<kuno> if you're a developer working on a project which has both python and
       javascript bits, is it really that much to ask that developer to have
       those package managers?
<kuno> (it's just a "sudo apt-get install npm")                         [14:53]
<paroneayea> kuno: it's a lot to ask them to *debug* all those things, and to
             have to run each package manager in turn.
<paroneayea> kuno: remember also how often python's package manager breaks
                                                                        [14:57]
<paroneayea> start adding more and more breakable language package managers
<paroneayea> and you're gonna have a bad time
<paroneayea> (also each one tends to take a really long time to run)
<paroneayea> so I do think it's onerous still
<kuno> paroneayea: right, but that's because python packages are notoriously
       bad about specifying the correct versions for their requirements ;)
                                                                        [15:00]
<paroneayea> kuno: not only!                                            [15:01]
<paroneayea> kuno: we've had a good number of other types of errors:
<kuno> (this is less of a problem with npm because "npm install some-package
       --save" does the right thing by default, and you have multiple versions
       of the same dependency in the tree without conflicts or trouble)
<kuno> +can                                                             [15:02]
*** azerus (~badass@unaffiliated/badass) has quit: Quit: Leaving...     [15:04]
<kuno> paroneayea: in a mixed javascript + python project, it just seems
       arbitrary to call requiring one of the package managers an onerous
       requirement, while requiring the other package manager is perfectly
       fine.                                                            [15:08]
<paroneayea> kuno: it's a python project with javascript dependencies
<paroneayea> just as so is it a python project with C dependencies :)
<kuno> :)                                                               [15:09]
<kuno> there is a problem with my previous argument that end-users shouldn't
       be using package managers at all, which is that it increases the
       distance between developers and end-users.  Which makes it more
       difficult for a curious end-user to tinker with stuff and become a
       developer.                                                       [15:10]
<kuno> in that sense I am in favour of improving our developer tools and
       package managers to such an extent that they could be used by an
       end-user.
<kuno> (but that seems impossible with the current state-of-the-art)    [15:11]
<paroneayea> agreed there kuno