Perl 6 - the future is here, just unevenly distributed

IRC log for #darcs, 2015-06-10

| Channels | #darcs index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:19 mizu_no_oto joined #darcs
01:59 mizu_no_oto joined #darcs
02:46 mizu_no_oto joined #darcs
03:07 c74d joined #darcs
04:12 sprang joined #darcs
06:50 dino- joined #darcs
07:21 c74d joined #darcs
08:35 alexei___ joined #darcs
09:10 alexei___ joined #darcs
10:47 alexei___ joined #darcs
11:10 mizu_no_oto joined #darcs
12:20 alexei___ joined #darcs
13:27 alexei___ joined #darcs
14:08 alexei___ joined #darcs
14:18 notdan uh shit I got a "pure" darcsden patch dependend on one of the local backend patches somehow  :S
14:18 alexei___ joined #darcs
16:06 burp joined #darcs
16:49 Heffalump notdan: you can hopefully rebase/amend your way out of that
16:50 Heffalump e.g. rebase suspend the pure patch, obliterate the local patches (in a fresh repo obviously), unsuspend the pure patch and resolve the conflict
17:18 Riastradh joined #darcs
17:24 notdan Heffalump: uh, I hate to admit that, but I actually have no clue how rebase works! :( I need to find more about it, definitely
17:25 notdan I already solved the issue tho, by finding the offending commit, unrecording the "pure" patch and recording only the parts that do not depend on the previous patches
17:25 notdan http://hub.darcs.net/simon/darcsden/compare/co-dan/darcsden
17:48 Heffalump right, you could also have used amend --unrecord to eliminate the bits that did depend on the others
17:49 Heffalump the rebase suspend workflow is generic in the sense that darcs will then tell you about the areas that did depend
17:53 Heffalump do you want to "meet" now? I should mostly be around except for a few interruptions for tunnels and walking home.
18:13 notdan Heffalump: actually, can you give a couple of minutes more?
18:13 Heffalump sure
18:27 notdan Alright
18:27 notdan I'm ready
18:31 alexei___ joined #darcs
18:32 Heffalump cool - so how's it going?
18:33 notdan this is the patch (against simon's darcsden): http://covariant.me/stuff/tmp/darcsden.dpatch
18:33 notdan it's going fine
18:33 notdan this week has not been as productive as I hoped, tho
18:34 notdan still have a wee bit stuff left to finish for school, but it's fine, shouldn't take too much time
18:35 notdan So one of the things that I added is HTTP testing with wreq and shelly
18:35 notdan darcsden-test-http should (using the Test.hs settings) create some repository structure and then test the basic functionality using wreq
18:36 Heffalump nice
18:36 notdan for now it only does two things: checks for status code (basically that nothing is throwing exceptions/not found/whatever) and checks for the description
18:36 notdan should be easy to make it check for parent repository
18:36 notdan that's another thing that I added -- support for parent repositories
18:36 notdan it looks in defaultrepo for the filepath and checks if it's correct
18:37 notdan another thing that should be working is branches and comparision -- but with a caveat!
18:37 notdan i had to modify darcs to add some functionality
18:37 notdan http://hub.darcs.net/co-dan/darcs-soc/patch/20150610144611-21ae5
18:38 notdan basically the reason for that is that most of the operations in darcs rely on the current directory, so darcsden sometimes uses commands like withCurrentDirectory ..
18:38 notdan which do not play well with relative paths in local storage
18:39 Heffalump looks reasonable - if you submit that on the darcs patch tracker hopefully we can get it into 2.10 soon (one comment - does it really work on general URLs rather than just local paths? I know the darcs code is already a bit confused about variable names there)
18:39 notdan http://hub.darcs.net/co-dan/darcsden-local/patch/20150610152430-21ae5
18:39 notdan Heffalump: that's a good question, and I was asking myself that as well
18:39 notdan it shouldn't work on general URLs
18:39 Heffalump why is local storage special compared to the normal backend?
18:40 notdan I mean, you can't really lock a remote url generally
18:40 Heffalump ok, perhaps just name the variable path or whatever then
18:40 notdan the question is just how exactly does darcs fails if we supply an actual remote URL
18:40 notdan I will investigate that and submit it to the patch tracker
18:41 notdan one question tho: you say you want to get those changes in 2.10, right? does that mean 2.10.1, strictly?
18:41 Heffalump right, the next 2.10.x release
18:41 Heffalump those will have the major advantage of being on hackage
18:42 notdan re: local storage vs normal backend: to think of it, it actually shouldn't matter; it is a question of specifying relative paths vs absolute paths
18:43 Heffalump where does a relative path come up, in the _prefs/defaultrepo file?
18:43 notdan oh and if you want to compile darcsden-local you should also fetch http://hub.darcs.net/co-dan/hsp -- it is related to that weird HTML problem that we talked about a couple of days ago; sorry, I still haven't played around with stripping whitespaces
18:43 notdan Heffalump: it can come up there if you write it yourself, your localRootDir can also be relative
18:44 Heffalump could darcsden calculate an absolute path instead?
18:45 notdan that is another option: for that we would have to modify BackendPermanentFileSystem
18:46 Heffalump that would be fine, those classes are just something I cobbled together to abstract out the backend, I always expected they'd need tweaking/refactoring
18:46 Heffalump I think I'd prefer that to changing darcs, partly because I don't quite trust the way darcs handles directories so am wary of nasty surprises by trying to make it do more with them.
18:47 notdan I see. Well, sure, let's go with that
18:49 Heffalump I'm just waiting for an entire stack of dependencies to build to try out your tests :-)
18:49 notdan Uh yeah, sorry for that
18:49 Heffalump it's only a tiny amount more than the normal darcsden stack
18:50 Heffalump I actually view it as a good thing that we're using the Haskell ecosystem well
18:51 notdan So I was thinking about how should we toggle whether user is logged in or not: because if darcsden is just run locally, IMO, the actual user should have all the powers as if he was the owner of all the repositories; however, if darcsden is there for serving repositories, noone should be able to login and modify anything
18:52 Heffalump hmm, I hadn't thought about a "local" instance serving repositories
18:52 notdan I tried just adding a field to settings, but I didn't work out yet, as I had to go deeper and deeper in darcsden functions
18:52 Heffalump wouldn't that imply things like running it as a daemon, which would be a bit odd for a single-user thing?
18:53 notdan Heffalump: well that's how I usually run haskell web servers
18:53 notdan e.g. i have two instances of gitit running being proxies through apache
18:53 Heffalump I see, fair enough
18:53 Heffalump I wonder if this is really two backends, that share a lot of code?
18:54 notdan i actually wanted to run an instance of darcsden-local on my shell and link you to that instead of sending dpatches, but then I realized that I don't have redis installed and thus I would have to tinker the webserver.hs part
18:54 Heffalump one for the "interact locally" workflow, where you might also want to integrate it on the command-line so that one command starts a server and launches a webbrowser to the right URL
18:54 notdan hm
18:54 Heffalump there is an alternative temporary backend to redis, you could probably just switch to that
18:54 Heffalump or maybe that's what you mean by tinkering with webserver.hs
18:55 notdan yeah exactly that; was trying to do that last minute
18:55 notdan well , maybe next time
18:55 Heffalump that would be quite cool, yes :-)
18:56 Heffalump another possible reason for divergence: if using darcsden "interactively" you ultimately want it to be able to see unrecorded changes. I don't think you want that for remote access.
18:57 notdan Heffalump: actually, this idea with a command-line tool is pretty cool: you can do stuff like 'darcsden init' in a darcs repository on your system and it would 1) ask you for metadata and store it 2) create a symlink in the darcsden-local root folder 3) open a browser
18:58 notdan Heffalump: ah, seeing unrecorded changes is important! i kinda haven't realized that
18:58 notdan hm that would require a lot of "deep" modifications :{
18:58 Heffalump I wonder if it even needs that much state, I would kind of like just to be able to do 'darcsden-open' and have it launch straight away. Missing metadata could be filled in later on-demand.
18:59 Heffalump it doesn't have to be part of your GSoC project to add handling unrecorded changes, but if we expect it to happen sometime we should plan for it
18:59 notdan yeah, definitely - it is very important
19:01 notdan but ok,if we are running darcsden  fully locally, the user should be basically always logged in as an admin, right?
19:02 Heffalump yes, I think so
19:02 Heffalump modulo making sure someone else can't get access by finding the right port!
19:03 notdan bind the server to 0.0.0.0 or 127.0.0.1 or something like that?
19:03 notdan i don't know much about network security unfortunately
19:03 Heffalump still vulnerable to other users on the machine
19:03 Heffalump (0.0.0.0 is wrong, that means every IP address)
19:04 Heffalump might be as simple as generating a username/pass to put in the URL though
19:15 notdan oh, so, btw, you mentioned you had a problem with darcsden chocking on big amount of repositories - i will try using 'dirstream' library
19:15 notdan i don't know much about it, but i am also not aware of any other alternatives
19:16 Heffalump how are you looking for directories at the moment?
19:16 Heffalump I wonder if just a slightly more sophisticated strategy would be enough
19:17 Heffalump though dirstream looks like the right solution in some sense, not sure what cost introducing pipes would bring though
19:17 notdan just using getDirecotyContents and identifyRepository
19:17 notdan cost as in computational cost or production cost?
19:17 Heffalump code complexity
19:18 notdan ah
19:18 Heffalump the way I understand things like pipes/conduit, you have to run everything in them
19:18 Heffalump but it's only a very superficial understanding
19:18 Heffalump so using getDirectoryContents recursively and then identifyRepository on each directory you find?
19:19 notdan yeah I was thinking maybe I can utilize  BackendPermanentM for that
19:19 notdan re: running everything in pipes
19:19 notdan Heffalump: yeah, modulo ., .., and _darcs
19:20 notdan I remember you said you had problems with symlinks - I am not sure what to do about it yet, I use symlinks for repositories  sometimes
19:20 Heffalump oh, that's interesting, might work
19:20 Heffalump (using BackendPermanentM that is)
19:21 notdan but following directories that you cannot access = definitely a bug
19:21 notdan <3 associated types
19:21 Heffalump identifyRepository looks like it works quite hard, you might consider just looking for _darcs directories yourself
19:21 Heffalump identifyRepository does stuff like reading the format, which I think can be deferred until someone wants to actually use the repository
19:22 Heffalump do you use symlinks in a way you'd want darcsden to traverse them, e.g. going outside your home directory?
19:22 Heffalump (if they're in your home directory it should find the originals anyway)
19:23 notdan Well the thing is, right now darcsden-local supports only top-level repositories -- because of those problems with nested repositories we discussed last meeting
19:23 Heffalump re BackendPermanentM/pipes, it's still quite a significant commitment to decide that everything runs in Pipes, even if it's easy code-wise to achieve
19:23 notdan so when I run it I have a directory with just symlinks
19:23 Heffalump you mean they need to all live in a single sub-directory of the chosen localRootDir?
19:24 notdan yeah
19:24 Heffalump you don't need to support nested repos to support repos in arbitrarly deep directory structures, do you?
19:25 notdan no, but most of the problems with nested repos are actually problems with nested directories
19:25 Heffalump oh, right
19:25 Heffalump I hadn't appreciated that
19:26 Heffalump I guess parsing the URL is tricky either way
19:26 Heffalump I think nested directories are quite important, at least to me
19:27 notdan yeah I agree
19:30 Heffalump so I guess the key design question is how the URLs would work
19:33 notdan yesy
19:35 notdan and the biggest issues here, as I see it, is the rise of code complexity and  amount of modifications to darcsden internals upon implementing a simple solution (like a URL param for a repository path or something)
19:35 notdan (is it "a URL" or "an URL", btw?)
19:35 notdan I actually have one hack in mind that might just work..
19:35 Heffalump "a URL" I think
19:36 notdan it consists of moving repoURL function in the typeclass, and overloading it in such a way that repoURL "/my/repo/" = "/localrepo?path=/my/repo&dispatch="
19:37 notdan then (repoURL "/my/repo" ++ "/patches") would be "/localrepo?path=/my/repo&dispatch=/patches"
19:37 Heffalump hmm, makes sense. It seems a shame to lose the nice-looking URLs we have now, but I guess they are only for internal consumption anyway
19:38 Heffalump you also need to make the routes work, right?
19:38 Heffalump I guess that might require some abstraction there
19:38 notdan then, of course we would have to manually do the dispatching
19:38 notdan which means data duplication (routes)
19:39 notdan unless we thinkg of a clever abstraction
19:40 Heffalump sm: if you're around, any thoughts on the issue of URLs for "local" darcsden repos? Main problem is it's hard to parse the current scheme when you have nested directories in play, e.g. a repo in 'darcsden/upstream'
19:40 Heffalump I guess the abstraction might be a simple as defining a type class or record to hold all the handlers, and then having the route->handler mapping be abstracted out
19:42 Heffalump hmm, how about just ending the repo part with a // ?
19:42 Heffalump http://localhost/darcs/screened//patches for example
19:43 notdan hm.. that might just work
19:43 Heffalump "" is the only other thing you can't have in a path, AFAIK
19:43 notdan still the same problem of dispatching
19:43 Heffalump and if there's no // then just assume that the path is exactly one element long
19:43 Heffalump well, then I think it's reasonable to change the general dispatch code to handle that case
19:43 Heffalump I can see a world where we also want structure in the "proper" server's repos
19:43 notdan well the dispatch code uses the standard snap mechanism for that
19:44 Heffalump I see, so can only recognise one path element at a time?
19:45 Heffalump I wonder about a nasty hack with one route per number of nested directories
19:46 Heffalump ":path1/:path2//", ":path1/:path2/:path3//", etc
19:46 Heffalump though that is pretty nasty
19:46 notdan haha
19:48 Heffalump and it would need duplicating across all the repo routes
19:48 Heffalump src/DarcsDen/Handlers/RepoHandlers.hs:196:41:
19:48 Heffalump Not in scope: ‘inits’
19:48 Heffalump Perhaps you meant one of these:
19:48 Heffalump ‘BS.inits’ (imported from Data.ByteString.Char8),
19:48 Heffalump ‘T.inits’ (imported from Data.Text), ‘init’ (imported from Prelude)
19:49 Heffalump know anything about that error off the top of your head?
19:49 Heffalump I'm using GHC 7.8
19:50 notdan uh crap
19:51 notdan my bad, this must have came up when i was editing that "" darcsden patchpure
19:51 notdan give me a sec
19:51 Heffalump ah, trivial missing import, easily fixed
19:53 notdan I think you need to grab this: http://hub.darcs.net/co-dan/darcsden-local/patch/20150610195139-21ae5
19:53 notdan just adding an import wont fix this, as I also renamed a function
19:53 Heffalump it worked for me...
19:53 notdan ah crumb is also defined in the where clause
19:54 notdan yeah  then it should only be a warning
19:59 Heffalump I get 7 tests passing and 3 failing with 500 errors, FYI. I might have misconfigured some settings though.
19:59 Heffalump the existing tests in darcsden aren't easy enough to run perfectly either
20:00 notdan hm, can you paste the log?
20:00 notdan or the output of darcs-test-httpp?
20:00 notdan *darcsden-test-http
20:00 Heffalump whole thing or just the failures?
20:00 notdan whole thing -- there might be a problem with the shell script part ):
20:00 Heffalump actually you'll probably need the error.log anyway
20:01 Heffalump the access and error logs are sadly silent :-(
20:02 Heffalump http://lpaste.net/134297
20:02 Heffalump well, not totally silent, but nothing useful in them
20:02 notdan uh my failure messages suck as well
20:02 sm hey guys
20:03 notdan hey simon!
20:03 notdan how is it going?
20:03 sm sorry I haven't been around much. Sounds like lots of progress
20:04 sm I always thought of the "local darcsden" as simply a UI for browsing the current repo. Managing multiple repos seems like a later step
20:05 notdan Heffalump: just a wild guess, but you you have anything in ../test/repos apart from the three repositories just created?
20:05 sm I don't see handling nested repos as very important
20:05 Heffalump notdan: no, I cleaned it out before the run
20:05 Heffalump and I changed the configuration so the path is /home/ganesh/darcsden/test-area rather than ../test
20:06 notdan sm: yeah, maybe not, but it's not that hard (I think) once you have repos in hnested directories figured out
20:06 notdan sm: which is the harder part :(
20:07 Heffalump sm: for me browsing a single repo at a time isn't all that valuable, it's being able to compare different local repos that I really want
20:07 Heffalump sm: but I imagine different people have different wants here
20:07 sm ok
20:07 sm how about darcsden . ../other-repo
20:09 Heffalump plausible, though I'm not sure if it's necessary to cut down on what notdan already has working to do that instead, if you see what I mean
20:09 notdan Heffalump: what happens if you set the localRootDir in Production.hs to /home/ganesh/darcsden/test-area/repos and just run the darcsden?
20:09 sm ah, well indeed. I haven't seen all that yet
20:09 notdan Sorry for asking you to test this by hand :(
20:10 notdan shit, this is really annoying
20:10 notdan you have to test your tests
20:10 sm tell me about it
20:10 Heffalump making reliable tests is hard work, it's not just you :-)
20:10 Riastradh Man, I was hoping to just prove my tests correct and be done with it...
20:10 sm I started writing tests to test my dev setup
20:11 Heffalump the Settings/Production.hs I have in this repo doesn't have a localRootDir setting at all, am I missing something?
20:13 notdan Heffalump: uh my bad
20:14 notdan Heffalump: can you grab this? http://hub.darcs.net/co-dan/darcsden-local/patch/20150610201308-21ae5
20:15 Heffalump (random feature request: be able to darcs pull single patches from URLs like the above)
20:16 sm notdan: at http://hub.darcs.net/simon/darcsden/patches I see co-dan's darcsden .. are these the current "pull requests" ?
20:16 notdan sm: yep, more or less
20:16 notdan sm: if you want to I can write up an explanation for every patch as an issue
20:16 sm if they're not, I won't attempt to review/merge them yet
20:17 sm I was thinking I'd look for some easy things to merge, to get this started
20:18 notdan well the thing is some patches there are completely unrelated to darcsden-local: (spacing before the website, moving 'crumb' & friends, some comments and cleanup)
20:18 Heffalump notdan: I've got the darcsden running now, what shall I visit?
20:18 Heffalump the main pages seem ok
20:19 notdan they should be mergable directly
20:19 notdan patches that modify typeclasses are there because it is better to merge things that are mergable frequently, apparently
20:20 notdan Heffalump can yorrect me if I am wrong
20:20 notdan Heffalump: /rep2/patches
20:20 sm if you can arrange for the things you feel are ready to merge to appear here - in one repo or in per-topic repos if you prefer - it'll help us coordinate. We can also do quick review runs here, probably no need to open issues
20:20 notdan erm /rep1/patches
20:20 notdan and /rep1/changes
20:20 Heffalump Request handler threw an exception:
20:20 Heffalump both getFiles and getBlob failed
20:21 Heffalump no more explanation that I can see
20:21 * sm gets lunch
20:21 Heffalump same error for changes
20:22 notdan sm: I have two repos currently: co-dan/darcsden and co-dan/darcsden-local. In darcsden I push only patches that should be independant and merable into upstream
20:22 sm great
20:22 notdan Heffalump: uh
20:25 notdan Heffalump: can you obliterate the last patch and pull from darcsden-local again?
20:26 Heffalump the WIP: patch?
20:26 notdan Heffalump: I appologize for that, I should have prepared better for the meeting.
20:26 notdan Yes
20:27 Heffalump notdan: no worries, it's development software.
20:27 notdan I haven't got a good hold of the workflow
20:27 sm we're all figuring it out
20:28 Heffalump as your first guinea pig I expect things to go wrong
20:29 Heffalump the local darcsden works at theat URL now
20:29 Heffalump and the tests all pass :-)
20:29 notdan ah finally
20:31 Heffalump that was pretty fast, it took me ages to get the last round of tests working (written by a previous SoC student), and then they clobbered the production hub.darcs.net instance when sm ran them
20:32 Heffalump btw the test harness did fail completely when I had the default directories of "../test", might just be that it didn't exist
20:32 Heffalump but that might be something you could do to make it more robust, make a directory first if necessary. Also perhaps have the default be inside the current directory.
20:35 sm notdan: nice patches, thanks! I have deployed them at hub-dev.darcs.net and merged, though not yet deployed to production
20:37 Heffalump notdan: so anyway, nice progress - anything more to discuss? Do you know what you're doing next? Also, you might want to consider blogging even if you don't have anything "finished" to show.
20:38 notdan Heffalump: I tried having it inside the source code directory - but then I forgot to 'cd' in a script and it recorded a bunch of things as patches in  darcsden. Good thing I did not test for obliterate :)
20:38 Heffalump :-)
20:39 notdan Yeah I should write a blog post about testing with wreq perhaps?
20:39 notdan I managed to use two hip libraries: wreq and Shelly, so that's fun
20:39 Heffalump ooh, yes, that sounds like a nice topic
20:39 sm notdan++
20:39 sm "docs or it didn't happen"
20:40 notdan hm so one of the questions that I had is this
20:40 notdan the "compare" button seems to appear only after you press the "branches" button
20:40 notdan is there a rationale behind this
20:40 sm probably not
20:41 notdan also, the compare button allows you to compare your repository against any other repository -- which is quite handy, but againn, is this the intended behaviour?
20:41 sm I believe that was by design, yes
20:42 notdan ok
20:42 sm although it's offering a lot of choices that will never make sense (unrelated repos)
20:43 notdan another question i had: can you point me to any docs about darcs rebase? i read the discussion on roundup but didn't really understand  a lot
20:43 notdan also didn't find anything in the manual :(
20:44 sm !
20:44 * sm is shocked, shocked
20:44 sm did you see rebase --help ?
20:44 Heffalump I blame the implementer, he's as lazy as that HTTP maintainer
20:44 sm :-)
20:45 notdan heh
20:45 Heffalump I did actually write some docs on the wiki
20:45 Heffalump I thought
20:45 notdan sm: well I don't really understand the whole "suspended " thing
20:45 Heffalump http://darcs.net/Ideas/RebaseStatus
20:46 notdan oh good
20:46 notdan i will read that
20:46 sm Heffalump is the expert, he wrote it. Keep bugging him
20:46 Heffalump it's out of date - e.g. rebase is in 2.10 now
20:46 Heffalump and yes, what sm said
20:48 notdan oh that reminds me, the binaries are out of date as well
20:48 notdan but i guess that's not a big issue atm
20:49 sm Heffalump: when you have time.. what's the benefit from http://hub.darcs.net/ganesh/darcsden-datafiles/patch/20150602172621-81bb2 ?
20:49 notdan well from the top of my head I don't have any more questions, but I guess I will keep bugging you throughout the week as well
20:49 Heffalump makes the "Darcs binaries for many platforms" link on the front page a bit of a lie :-)
20:49 Heffalump notdan: please do :-) Want to fix the next meeting now or later?
20:49 notdan later is preferable
20:50 Heffalump sm: the immediate driver was that I am trying to deploy darcsden with nixops. And when it builds with nix and gets copied to an install location, the source tree isn't available.
20:50 Heffalump sm: the principled argument for doing it the "new" way is that it's how you're supposed to deploy data with cabal built binaries, so it will fit in well with any distro's automated packaging
20:51 sm I see.. so I guess it was also broken for someone installing from hackage ? Except it isn't on hackage yet
20:51 Heffalump notdan: ok, let me know when you have an idea when would be convenient
20:51 Heffalump sm: right
20:52 Heffalump sm: but not being on hackage isn't really the point, it's that 'cabal install' doesn't produce a binary that just works independent of the source tree
20:52 sm great. Merged your -datafiles branch, thank you
20:52 * sm nods
20:52 Heffalump cool, thanks. I guess you realise it might affect your own deployment workflow depending on exactly what you do now?
20:53 sm uh.. ok not that I've noticed. I'm using cabal lately it seems
20:55 Heffalump ok, if you use cabal install yourself it should be fine
20:55 Heffalump doing cabal build then running it from the dist folder might not work though
20:55 Heffalump hmm, which makes me think an override command-line option would be a good developer-friendly thing to add
20:55 Heffalump i.e. an option to override the data path. I'll have a look at doing that.
20:58 sm yes I normally copy from dist/build to /usr/local/bin
20:58 sm some things can also be embedded, eg with file-embed
20:59 Heffalump I considered doing that, but they'd need to be un-embedded at runtime, or the file serving would need to change
20:59 sm ah
20:59 Heffalump if you just copy a binary from dist/build to /usr/local/bin without using cabal install or cabal copy then I'm not sure this will work for you now?
21:00 sm it does, who knows why..
21:01 Heffalump interesting :-)
21:02 sm oops.. now it doesn't (just deployed)
21:02 * sm undeploys
21:03 sm guess I'll switch to cabal install
21:03 sm that does make life more complicated, if you are running multiple versions
21:04 sm so being able to override that with an option does sound nice
21:04 Heffalump ok, I'll do that asap
21:04 sm no hurry - great
21:05 Heffalump would you want it to be a command-line flag or a config option?
21:06 sm I'm not sure
21:06 Heffalump I guess a config option would be kind of restoring rootDir but as a optional option instead (and I think with a better name)
21:07 sm do we have any command-line options right now ?
21:07 sm not really
21:07 sm so config file seems easiest
21:08 Heffalump --install and --service
21:09 Heffalump anyway yes, I agree config option is more natural
21:10 sm it's also possible this latest deployment issue can be fixed just by updating my scripts, eg I'm not using the new --config option  yet
21:18 Heffalump probably if you tell cabal where you'll be installing to, then cabal install will do the right thing
21:18 Heffalump at least I'd hope so, that's really the point of integrating with it
21:19 Heffalump cabal install --prefix=/usr/local maybe
21:26 notdan one problem that I had with data-files and cabal is that you cannot tell cabal to make relative data paths
21:26 notdan which is *really* problematic during deployment
21:27 notdan unless you have root access on a machine
21:27 sm Heffalump: good idea
21:28 notdan i tried to deploy gitit to my shell, endedd up making a new VM with exactly the same OS version and with similar directory structure
21:28 sm notdan: yes indeed. It's really no good for "just works" end-user deployment
21:28 notdan hm which is actually going to be problematic for deploying and distributing darcsden-local :(
21:28 Heffalump notdan: why can't you just tell it to use the path you're going to deploy to?
21:29 sm or we can teach it to serve embedded files
21:29 notdan Heffalump: you have to recreate the same directory structure
21:29 Heffalump I agree that deployments being non-relocatable is a nuisance, but it doesn't seem insurmountable
21:29 Heffalump notdan: which directory structure?
21:29 notdan well my hosting provider uses Kerberos and openafs so that was an dditional layer of complexity
21:29 sm then again, darcsden users are going to be technical so YAGNI
21:29 Heffalump I think serving embedded files is quite attractive
21:29 Heffalump having a single standalone binary would be nice, though it'd still need a config file
21:29 notdan Heffalump: well if you want to store your config in your home directory, you should have exactly the same directory on the machine you are compiling the binary
21:30 sm hledger-web does it somehow
21:30 sm no config file
21:30 Heffalump notdan: I don't think it's strictly necessary, cabal is designed to integrate well with distro packaging, which typically doesn't have write acces to the final deployment directory
21:30 sm local darcsden could probably figure things out without a config file, you'd think
21:31 Heffalump sm: yes, I hope so
21:31 alexei___ joined #darcs
21:32 notdan Heffalump: but distro packages are sort of non-relocatable
21:32 Heffalump notdan: right, but the point is you can build on one machine without write access to the deployment path
21:32 Heffalump and then deploy
21:33 Heffalump anyway, apologies to anyone I've inconvenienced with the data-files thing, I'll add the config option as soon as I can
23:02 dino- joined #darcs

| Channels | #darcs index | Today | | Search | Google Search | Plain-Text | summary