First run feedback
Justin Love
1. Question about handling repo-specific features. Do you have a
definite plan for this yet, (even "not supported") or is it more cross
that bridge when we get there? I've been assuming some kind of
feature sniffing would be involved for some things.
2. Concern that it might be good for scripting but not for regular
use. Perhaps I need a better customization example. I saw a similar
comment on an amp article from some time ago. I was wondering how you
felt about focusing on making a better argument versus making a better
scripting environment and perhaps turning that into a full fledged
interface later on.
--
Justin Love -- http://JustinLove.name/
http://ComputerGeneratedDreams.com/
"[T]he woods would be silent if no bird sang except the best."
- Henry Van Dyke
Michael Edgar
On Nov 2, 2010, at 4:03 PM, Justin Love wrote:
> I may want to make the presentation a little more inactive, but Amp-wise:
>
> 1. Question about handling repo-specific features. Do you have a
> definite plan for this yet, (even "not supported") or is it more cross
> that bridge when we get there? I've been assuming some kind of
> feature sniffing would be involved for some things.
Well, the thing is repositories already need to have some kind of #capabilities
function to return a list of capabilities since different versions of different systems
have different capabilities. Mercurial has around 5 or 6 it uses primarily during
push/pull negotiation. So we'll extend that, likely.
>
> 2. Concern that it might be good for scripting but not for regular
> use. Perhaps I need a better customization example. I saw a similar
> comment on an amp article from some time ago. I was wondering how you
> felt about focusing on making a better argument versus making a better
> scripting environment and perhaps turning that into a full fledged
> interface later on.
It might seem at first like it's chasing the long-tail, right? Except it's important
to think about every time a VCS didn't do something by default that you wish
it did. About how adding a test-running hook before pushing is trivial and how
changing the defaults of options is trivial and so on. Running queries on your
commits - regardless of repo, output formats, etc. - can be much, much simpler.
At Google (interned there this Summer, starting next Fall) they have PRESUBMIT.py
files in each directory that requires custom presubmit hooks. This is hard-grafted onto their
p4 environment because there's no easy way to handle this scenario without
building on top. There's no customization allowed.
What I'm getting at is that... you're in part right. Amp's customization more useful
the less you've used it, in casual settings. You customize the commands you like
to your usage, you occasionally think of a script you like and write that... but I think
the potential of project-level things to be built on top of Amp, given its built-in customization, means
we'll see a lot of killer-solutions that use Amp as their base. Because doing this stuff
with other systems isn't even worth trying.
Quick example: What about, after your pre-push hook calls `rake` to kick off
default rake tasks, the results (either success/failure or more detailed test results)
are shipped off to a server that reports workstation build results. The code you wrote to
do that (probably 15 lines, max) would work with *every project* Amp works with!
Justin Love
> Well, the thing is repositories already need to have some kind of #capabilities
> function to return a list of capabilities since different versions of different systems
> have different capabilities. Mercurial has around 5 or 6 it uses primarily during
> push/pull negotiation. So we'll extend that, likely.
Sounds good. P.S.: non-fncache repos seem to be broken in John Locke.
Are you tracking bugs somewhere at this stage?
> to think about every time a VCS didn't do something by default that you wish
> it did. About how adding a test-running hook before pushing is trivial and how
> changing the defaults of options is trivial and so on. Running queries on your
> commits - regardless of repo, output formats, etc. - can be much, much simpler.
Am I following you right - hooks and option are the easy things with
existing systems, and you want to extend that to the rest?
> Quick example: What about, after your pre-push hook calls `rake` to kick off
> default rake tasks, the results (either success/failure or more detailed test results)
Once you're invoking rake, which is already running Ruby code, what is
the added value? That you don't have to add that feature to every
Rakefile?
Michael Edgar
On Nov 3, 2010, at 1:07 AM, Justin Love wrote:
> On Tue, Nov 2, 2010 at 19:16, Michael Edgar <ad...@carboni.ca> wrote:
>> Well, the thing is repositories already need to have some kind of #capabilities
>> function to return a list of capabilities since different versions of different systems
>> have different capabilities. Mercurial has around 5 or 6 it uses primarily during
>> push/pull negotiation. So we'll extend that, likely.
>
> Sounds good. P.S.: non-fncache repos seem to be broken in John Locke.
> Are you tracking bugs somewhere at this stage?
We accept bug reports in Github right now. We have a lighthouse but I honestly
can't work too well with it.
>> to think about every time a VCS didn't do something by default that you wish
>> it did. About how adding a test-running hook before pushing is trivial and how
>> changing the defaults of options is trivial and so on. Running queries on your
>> commits - regardless of repo, output formats, etc. - can be much, much simpler.
>
> Am I following you right - hooks and option are the easy things with
> existing systems, and you want to extend that to the rest?
I'm sorry – I was saying Amp would make it trivial to change all those things. I mean,
you can add hooks and option overrides in other systems, but it requires some INI
magic and wizardry. Amp's goal is to make it dead simple to make those changes,
*and* to unify the techniques for modifying built-in behavior and adding new behavior.
>> Quick example: What about, after your pre-push hook calls `rake` to kick off
>> default rake tasks, the results (either success/failure or more detailed test results)
>
> Once you're invoking rake, which is already running Ruby code, what is
> the added value? That you don't have to add that feature to every
> Rakefile?
This is a bit controversial, but here's my opinion: I think Amp could and should replace
rake as the standard Ruby task-running tool. Our commands are far more powerful
and more easily customizable. Rake's command-running ability is extremely useful,
but kind of just tacked on to its Make/pattern-matching rule system. The one thing
I like is that you can run multiple tasks in one invocation, but the annoying part is
none of those tasks can be customized via the command-line, without setting environment
variables or the strange bracket syntax.
Rake will always have a role. But I think amp, as a task-running tool with VCS integration,
and extremely powerful commands, is strictly more powerful and superior to Rake for 99.9%
of the use-cases that users use Rake for these days.
Might want to play that bit down a bit. Might send people walking. But it seems true to me.
Ari Brown
On Nov 3, 2010, at 1:28 AM, Michael Edgar wrote:
>> Once you're invoking rake, which is already running Ruby code, what is
>> the added value? That you don't have to add that feature to every
>> Rakefile?
>
> This is a bit controversial, but here's my opinion: I think Amp could and should replace
> rake as the standard Ruby task-running tool. Our commands are far more powerful
> and more easily customizable. Rake's command-running ability is extremely useful,
> but kind of just tacked on to its Make/pattern-matching rule system. The one thing
> I like is that you can run multiple tasks in one invocation, but the annoying part is
> none of those tasks can be customized via the command-line, without setting environment
> variables or the strange bracket syntax.
Certainly, this is feasible. I could use my fork to cut my waffles, and then I wouldn't need to grab a knife! But this is not appropriate for fine dining. The real question is why are waffles being served at a classy restaurant, but that is neither here nor there.
I disagree. Rake has its place and it should be used as such. Rake does not manage versions. Amp does. Amp has a better command system in my/our opinion, and that's probably because we fucking wrote it. But Amp was not designed to be a build program.
In keeping with the Unix tradition, we should do one thing and do it well. If we happen to overlap with Rake, oh well. We can either concede that territory to Rake or not care. The GNU philosophy would be to annex that shit like it's Texas circa 1837.
Michael Edgar
Here's a few things that are true of 99% of the people who will ever even see Amp:
1. They use Rake *solely* to run a block of Ruby code specified in their Rakefile
2. Rake does not allow those blocks of code to be customized. Ever want to do something nonstandard, or extend Rake::TestTask? It's horrible.
3. If they use Amp, they have access to the identical functionality than Rake provides, and in fact they have access to far more functionality than Rake provides. Amp's command system is a strict superset of Rake's command system.
4. Again, all they use Rake for is to run rake tasks, namely, named blocks of code in a file.
5. They can define amp commands with an equal amount of effort, by putting the same block of code in their Ampfile instead of their Rakefile
6. After they make an amp command, they will eventually see that there's no reason to ever add another task to their Rakefile. Ever. For any reason.
Can you please explain what step there is illogical?
Justin Love
> Can you please explain what step there is illogical?
The key philosophical difference is that rake was built to be a
dependency build tool. It's tasks run only once, no matter how many
things depend on them - which actually makes it a pain if you do want
to run something twice. It probably has been used for a lot of thing
that don't really fall into dependency management. Perhaps we should
(later) build a rake extension that makes it easy to run amp commands,
so people can do dependency resolution in rake and use Amp for custom
code.
Ari Brown
On Nov 3, 2010, at 9:28 AM, Michael Edgar wrote:
> Can you explain why anyone should write a rake task in an Amp-managed repository?
>
> Here's a few things that are true of 99% of the people who will ever even see Amp:
>
> 1. They use Rake *solely* to run a block of Ruby code specified in their Rakefile
> 2. Rake does not allow those blocks of code to be customized. Ever want to do something nonstandard, or extend Rake::TestTask? It's horrible.
> 3. If they use Amp, they have access to the identical functionality than Rake provides, and in fact they have access to far more functionality than Rake provides. Amp's command system is a strict superset of Rake's command system.
> 4. Again, all they use Rake for is to run rake tasks, namely, named blocks of code in a file.
> 5. They can define amp commands with an equal amount of effort, by putting the same block of code in their Ampfile instead of their Rakefile
> 6. After they make an amp command, they will eventually see that there's no reason to ever add another task to their Rakefile. Ever. For any reason.
>
> Can you please explain what step there is illogical?
Because the way your application builds is not relevant to a version control system. I'm not saying that you 6 step program to enlightenment is illogical, I'm just saying that I disagree that we should aim to replace Rake.
We have a lot of overlap with Rake. At the same time, Rake offers things that we don't. Sure, we could accumulate enough stuff to do EVERYTHING that Rake and all of its extensions do, but really, do we want to? Do we want to add that bloat and **maintain** it? What if they really want to use Make? or Rant? or Ant? or Maven? or one of a million other things? Rakefiles are already written in the world. Nobody besides us few have Ampfiles. Yes, it's easy. But they would still have to move everything over to Amp.
Also, if Rake breaks, they still have Amp. If Amp breaks, they still have Rake. It compartmentalizes issues.
Michael Edgar
On Nov 3, 2010, at 4:06 PM, Ari Brown wrote:
>
> On Nov 3, 2010, at 9:28 AM, Michael Edgar wrote:
>
>> Can you explain why anyone should write a rake task in an Amp-managed repository?
>>
>> Here's a few things that are true of 99% of the people who will ever even see Amp:
>>
>> 1. They use Rake *solely* to run a block of Ruby code specified in their Rakefile
>> 2. Rake does not allow those blocks of code to be customized. Ever want to do something nonstandard, or extend Rake::TestTask? It's horrible.
>> 3. If they use Amp, they have access to the identical functionality than Rake provides, and in fact they have access to far more functionality than Rake provides. Amp's command system is a strict superset of Rake's command system.
>> 4. Again, all they use Rake for is to run rake tasks, namely, named blocks of code in a file.
>> 5. They can define amp commands with an equal amount of effort, by putting the same block of code in their Ampfile instead of their Rakefile
>> 6. After they make an amp command, they will eventually see that there's no reason to ever add another task to their Rakefile. Ever. For any reason.
>>
>> Can you please explain what step there is illogical?
>
> Because the way your application builds is not relevant to a version control system. I'm not saying that you 6 step program to enlightenment is illogical, I'm just saying that I disagree that we should aim to replace Rake.
Except Rake **isn't a build tool**. Not to 99% of its users. That's the point. I never said we should replace rake entirely. You're oversimplifying my point over and over again. You're not separating "rake as a build tool" from "rake as it is commonly used" and assume they're identical when in fact they have extremely little overlap.
> We have a lot of overlap with Rake. At the same time, Rake offers things that we don't.
... not to rails developers. Not to most ruby developers. How many ruby projects are there on github that actually use Rake as a build tool, with file rules matching '.o' to '.c' and whatnot, and how many use it to define repetitive tasks they want to run from the command line (like rake spec, rake test, rake features, rake gemspec, rake gemcutter:release, rake version:bump:minor...) We do all these things better.
> Sure, we could accumulate enough stuff to do EVERYTHING that Rake and all of its extensions do, but really, do we want to? Do we want to add that bloat and **maintain** it?
I haven't suggested adding a single feature... once. Why do you think I am? I've suggested that people observe that with our existing feature set, we are a better option than rake for them.
> What if they really want to use Make? or Rant? or Ant? or Maven? or one of a million other things? Rakefiles are already written in the world. Nobody besides us few have Ampfiles. Yes, it's easy. But they would still have to move everything over to Amp.
Amp is a development tool. A highly generic one that has deep VCS integration. I'm suggesting that people who want to use Amp should discontinue the use of what began as a build tool to instead move to a more powerful environment for defining repetitive development tasks.
> Also, if Rake breaks, they still have Amp. If Amp breaks, they still have Rake. It compartmentalizes issues.
If Rake breaks right now, you're SOL. What's your point? You don't decide a tool's role based on what happens if we break it.
Ari Brown
Then if you're not suggesting adding anything, then what are we arguing about? Let the people use it as they will.
Michael Edgar
The discussion was about why people should use Ampfiles vs Rakefiles, and
what role custom commands/scripts have in a potential user's workflow. Justin
asked:
> Once you're invoking rake, which is already running Ruby code, what is
> the added value? That you don't have to add that feature to every
> Rakefile?
Honestly, you wouldn't even need to shell out to rake to run tests, you could run
them directly with an Amp test-command. Which could be generated just as
easily as Rake test tasks, only they'd be more powerful, because they could
take options and arguments.
"Let the people use it as they will": we have to explain how people should use our
tool, Ari. It's our responsibility to develop what the best practices and uses are of
what we're providing. You're not going to get much positive feedback if you stick a
complex software system in someone's lap, throw a couple docs pages up and say
"figure it out for yourself."
Since Justin is giving these presentations in part to share these points, it's important
to discuss them.
Justin Love
> easily as Rake test tasks, only they'd be more powerful, because they could
> take options and arguments.
> Since Justin is giving these presentations in part to share these points, it's important
> to discuss them.
I haven't done much with Rake tasks, such as getting into options and
such. Do you have an example that would have been more cleanly
implemented in Amp?
Michael Edgar
On Nov 3, 2010, at 4:59 PM, Justin Love wrote:
> On Wed, Nov 3, 2010 at 15:54, Michael Edgar <ad...@carboni.ca> wrote:
>> easily as Rake test tasks, only they'd be more powerful, because they could
>> take options and arguments.
>
>> Since Justin is giving these presentations in part to share these points, it's important
>> to discuss them.
>
> I haven't done much with Rake tasks, such as getting into options and
> such. Do you have an example that would have been more cleanly
> implemented in Amp?
Well that's just the thing... you can't really. The preferred way to pass arguments into
a rake task to set environment variables.
Thousands of ruby developers run "rake test" every hour, and there's no way to modify
that command in a natural way. Consider this extremely common case, where you have
small, medium, and large tests. In rake, you do
rake test:small # for small tests
rake test:medium # for small tests
rake test:large # for small tests
rake test:all # alias for small, then medium, then large
Delightful. In Amp, you could add options:
command "test" do |c|
c.opt :small, 'Run small tests', :short => '-s'
c.opt :medium, 'Run medium tests', :short => '-m'
c.opt :large, 'Run large tests', :short => '-l'
end
amp test -s -m # small and medium tests
Your command already inherits the :verbose option so it can handle output differently
if --verbose is on or off. This is not an option for rake: you can't take a command-line option
like --verbose when running your tests.
Ari Brown
On Nov 3, 2010, at 4:54 PM, Michael Edgar wrote:
> Read back in the thread.
>
> The discussion was about why people should use Ampfiles vs Rakefiles, and
> what role custom commands/scripts have in a potential user's workflow. Justin
> asked:
>
>> Once you're invoking rake, which is already running Ruby code, what is
>> the added value? That you don't have to add that feature to every
>> Rakefile?
>
> Honestly, you wouldn't even need to shell out to rake to run tests, you could run
> them directly with an Amp test-command. Which could be generated just as
> easily as Rake test tasks, only they'd be more powerful, because they could
> take options and arguments.
People use Rakefiles for the features they have and the libraries that Rake comes with. I assumed that you meant everything that can be done with Rake, not just a subset of its features. If someone wants a general shortcut, then yes, they can just throw it in an amp command. IF that's what they want to do.
Right now Amp is a VCS. If we want it to be more, then ok, that's fine, but that's a different discussion unto itself. We probably shouldn't be advocating conflating Rake and Amp at this point, since they serve different purposes. We should teach people how to make their own commands. If they want to make a command to serve them breakfast, sweet deal. Who cares. But we shouldn't go around telling that that's wise.
Michael Edgar
I honestly don't see why making an Amp command that runs tests would be a bad
thing, for example. It'll instantly allow people to add after-test hooks that could do
something with the VCS, such as tagging the most recent build success or hell,
auto-bisecting on test failure.
Ari Brown
Ari Brown
On Nov 3, 2010, at 5:15 PM, Michael Edgar wrote:
> I honestly don't see why making an Amp command that runs tests would be a bad
> thing, for example. It'll instantly allow people to add after-test hooks that could do
> something with the VCS, such as tagging the most recent build success or hell,
> auto-bisecting on test failure.
Adding a hook is one thing, but having a command `amp test_my_shizzle` is mixing up the purpose of a VCS.
Michael Edgar
How could amp have a hook into the test runner if it isn't itself running the tests?
The second bit brings up the fundamental disagreement:
And why is Amp *only* a VCS and not a general development tool? We *aren't* just a VCS because we provide
access to our API for general use as a library. Why should the definition of `amp`, the tool, be restricted to
*only* version-control related operations when it requires no change to the tool itself to add general development
features that can take advantage of the VCS itself?
Ari Brown
On Nov 4, 2010, at 3:08 PM, Michael Edgar wrote:
> How could amp have a hook into the test runner if it isn't itself running the tests?
> The second bit brings up the fundamental disagreement:
>
> And why is Amp *only* a VCS and not a general development tool? We *aren't* just a VCS because we provide
> access to our API for general use as a library. Why should the definition of `amp`, the tool, be restricted to
> *only* version-control related operations when it requires no change to the tool itself to add general development
> features that can take advantage of the VCS itself?
Because that's really all we've done so far. We've extended the utility of a VCS, but we really haven't done much beyond that, and I personally don't think we should venture into new territory until we've solidified what we are already laying claim to. Let's just not get ahead of ourselves. I fully support being more of a workshop than just a clerical aid,