<sferik>
should the `libs` directory be ignored in my project's .gitignore?
<asterite1>
It's a crystal file
<asterite1>
Yes, I think so
<sferik>
what's the difference between libs and .deps/
<sferik>
asterite1: I guess that should also be ignored?
<sferik>
asterite1: as well as the .deps.lock file
<asterite1>
libs is in the path by default, same as src
<asterite1>
Yes
<asterite1>
But…
<asterite1>
We started this command just some weeks ago and it still needs a lot of thought
<asterite1>
Right now I would advice to do this:
<asterite1>
Mmm… Well, yes, basically what you said, put libs and .deps in the ignore
<asterite1>
But, for example, if you develop against a library and need to uppdate it, there's no 'deps update' command, you have to delete it and run the command again
<asterite1>
Also, there's no way to work against a local path
<asterite1>
Because… we started it just very recently
<asterite1>
That's why I wouldn't depend that much on deps (no pun intended :-P)
<sferik>
asterite1: okay
<sferik>
asterite1: I am also interested in working on a REPL, as I mentioned earlier
<sferik>
asterite1: I started spiking something out, but didn't make it very far
<sferik>
asterite1: I agree, it will be difficult, but I think it is possible
<sferik>
asterite1: however, it might require some changes to the language itself :-o
<sferik>
asterite1: but I'm not sure about that
<asterite1>
changes like what?
<sferik>
asterite1: I'd like to spend some more time investigating
<sferik>
asterite1: let me follow-up when I have more information
<asterite1>
A possibility would be to have a different backend, a way to generate code maybe less efficiently but with more reflection, but only for the REPL
<asterite1>
(but then that would make it impossible to connect to an existing process)
<sferik>
asterite1: that's would be less than ideal, but might be a good way to start
<sferik>
asterite1: by the way, I am very inspired by Crystal
<sferik>
asterite1: I know it is still early, but I think what you have done is very impressive
<sferik>
asterite1: one more questions about porting the Twitter library...
<asterite1>
:) I imagined you would ask something like that
<asterite1>
No, there isn't… and right now we are like http specs
<asterite1>
We thought about some possibilities
<asterite1>
One is to use netcat so simulate http requests… that good thing is that this will mock the very low level, so it'll probably work (although maybe be a bit slower?)
<sferik>
asterite1: okay, but there's no good way to specify netcat as a dependency, is there?
<asterite1>
Another is to allow doing something like `require "net/http/mock"' and that would change HTTP::Client to allow mocking functionality
<sferik>
asterite1: I guess I'll need a Makefile
<asterite1>
No, there isn't
<asterite1>
But I think testing a rest api like twitter doesn't add a lot of value
<asterite1>
like… those specs are "I expect a post here with this info" and then on the real code you do a post there with that info
<sferik>
asterite1: yes and no
<asterite1>
then when the api changes you actually don't know that something really broke, and then you change it in both places
<sferik>
asterite1: I have found tests like those to be useful for saying, "I expect this request will be executed exactly 1 time"
<asterite1>
Ah, I see…
<asterite1>
Another option we have in mind is to support mocks in the language, although we don't know yet how to do it (we have some basic ideas)
<sferik>
asterite1: I should be able to work around it for now
<sferik>
asterite1: any plans to support new-style RSpec syntax in the spec library?
<sferik>
asterite1: my fingers have gotten very used to typing `expect` instead of `should`1
<sferik>
asterite1: again, not a big issue, just a question
<asterite1>
Yes, we could do it… I'm not sure what was the problem with "should"
<sferik>
asterite1: I think the issue was monkey-patching every object to have a `should` instance method
<asterite1>
Why would anyone else define a should method?
<asterite1>
I mean, I can't imagine "should" to have another meaning
<sferik>
asterite1: ¯\_(ツ)_/¯
<asterite1>
unless it's another spec framework, but then there would be no conflict :)
<sferik>
asterite1: yeah, I think it was more of a philosophical concern
<sferik>
asterite1: it doesn't bother me that much, either way
<asterite1>
I think we can add both ways, it should be pretty easy
<sferik>
asterite1: I actually prefer `must` to `should`
<asterite1>
In fact something that we dislike more right now, because of the way things are, is that eq, be, be_a, etc., are global methods… maybe `expect(1).to.eq(…)` would be better
<asterite1>
I never understood why there needs to be a space after `to`, `should`, `should_not`
<asterite1>
By the way, there's no `before(:each)` either yet :(
<sferik>
asterite1: that's another argument for wrapping the expectation
<asterite1>
In fact, maybe it would be better for us to do something like Test::Unit instead, because rspec is very hard to simulate right now :(
<sferik>
asterite1: then eq, be, be_a, etc. don't need to be global
<sferik>
asterite1: yeah, I actually don't have a strong preference
<sferik>
asterite1: i work in projects that use both RSpec and Minitest
<jhass>
When toying around with an alternate spec implementation, I got as far as being able to make be, eq and so on only available in the Context class that's created by describe
<sferik>
jhass: nice!
<jhass>
but I think before/before(:all)/let just won't work, since we can't dynamically attach methods to a particular instance
<asterite1>
You think having something like test_unit would be very bad? It's not that idiomatic but you can do more things with less magic
<jhass>
I think I could imagine a hybrid to be viable
<jhass>
class MyTest < Spec; let(:foo)... it ".."... end;
<jhass>
without context nesting
<asterite1>
You are right… let could easily be implemented as a macro like that
<asterite1>
but it'll be one of the few macros we would need
<jhass>
yes, I think if we want a nice DSL there, macros are what's needed. I just would like them to be scoped in some way, not polluting the global namespace
<asterite1>
Agreed
<asterite1>
Well, lunch time… talk to you later :)