You can clone with
No one assigned
It has been a hot topic the past week, but it has also been a sore point for a long time and that is that getting a proper Ruby and gems installation isn't nearly easy enough. Anecdotally, I've seen dozens of people struggle with their Ruby installs and in particular the Windows users have an extremely hard time of it.
I propose we create an official sub-project, sproutcore/build_tools, based on Node.js that will become a 1-to-1 replacement of Abbot. Here's how I see it, but please throw in your comments below and educate me:
Like I said, please weigh in below.
1+ Node based build tools
I don't have anything against Abbot, it's got it's share of bugs and I think it has suited us well for a while. My primary reason for voting for Node based build tools is I have very little experience with Ruby. Abbot is very tough for me to develop and debug because of my lack of knowledge of Ruby. Even more so I find it a pain to setup and maintain a Ruby environment. Ultimately this all falls back to my lack of Ruby knowledge and I realize that.
In my opinion it makes SproutCore less attractive for new users. When the company I work for first evaluated the use of SproutCore as a web framework some of the developers, myself included, viewed the Ruby build tools as a disadvantage when compared to other frameworks because of the pain involved with getting an environment setup. In fairness things have gotten better since then, we even have installers (pkg and exe) to make it easier for new users.
+1 Node based build tools
I used garçon fine in earlier versions of SproutCore, and have helped Maurits Lamers in recent explorations to move it forward to the current master. I'll let Maurits speak about progress he has made there, which sounds solid.
I am using ThothSC/Thoth for my backend, behind which I use python. Thoth is also written in node.js by Maurits Lamers. I have helped him with testing all along, even in its earlier incarnations, and have learned much in the process. Recently, I needed to add image uploading for my app, so naturally I looked at my options either in node.js by modifying Thoth or in Python, which I've done before quite a bit. I decided to try it in node.js, having seen node-imagemagick, node-canvas, and other graphics libraries. So far, node-imagemagick is only used for a simple call to im.identify to get image size data, and node-canvas, backed by the Cairo graphics library, is used for image resizing and thumbnails. It seems to work well, and I'd like to add some bells and whistles for backend image enhancement and manipulation using node-canvas.
This experience got me to thinking about the next generation of development tools for SproutCore. If we were to determine that one or several of these node.js graphics libraries are suitable for use, particularly if the dependencies are manageable for an installation package, we can dream up new ways of building tools. One way would be to stick to enhancing garçon itself, along the same lines that Chance worked. It is also possible to build a separate set of command line tools for the graphics handling sides of things. From my experience doing this sort of thing in python, it is best to build smaller tools that work standalone, then as you need to, either as part of an encompassing command line tool or as services used by a graphical user interface, you have maximum flexibility, at the cost of having to manage the different smaller bits. We have good repository tools that make management easier nowadays. And, about that graphical user interface possibility: I've also been thinking, and mentioning in irc, that we could build a simple SproutCore frontend to such a toolkit. For example, maybe one page of the app would be "button builder" where you select an image from your hard drive and fiddle with sliders, but all you would be doing is setting parameters for a call to one of the aforementioned command line graphics tools in node.js. A person with a more unixy preference could stay at the command line and work with scripting of the command line node.js tools, whereas a person, especially a new user, might like the convenience of the GUI, not even realizing perhaps that they are driving the node.js tools working behind the scenes.
But of course, such dreams are dependent on the size of the community, even if technically sound and viable within a broad ecosystem.
Also, I forgot to mention, that there could be a healthy draw of involvement from the community of node.js developers with the use of node.js build tools, and especially if we can use npm successfully.
+1 for node.js buildtools (of course :) )
I think that it is important to make a distinction between the version by Martin and by me, as my version (which lives on https://github.com/mauritslamers/garcon/tree/sc btw, not on master) is a SCified version with a number of changes to the workings (bundle support) and API (different approach to handlers).
I think it is important to make a choice of one of these versions. My version has a dependency on the SC runtime (and a few foundation things) from 1.4.5.
Moreover there is the issue of different sproutcore versions and how to support it. In the past different versions of SC have been accompanied by different versions of abbot. If this is also the way chosen for garcon, and my SCified version of garcon is chosen, it might be easier to integrate garcon within sproutcore itself. Installing sproutcore then also installs the right build tools in one go.
Do we have a canonical set of source and expected result files that we can use as an acceptance suite? I recently had a conversation with Alex Iskander about regressions within chance that occurred when they moved from the SCCompress.jar to a Ruby based system.
I also like Maurits' idea of integrating the build tools into Sproutcore.
+1 I expect the challenges to fully replacing abbot master to be JS implementations of Sass/SCSS and Chance
Spurred by a desire to finally grok build tools, to act on some of the ideas described above, and to learn coffeescript, I have started rewriting garçon in coffeescript as a new program called Busser: https://github.com/geojeff/busser [EDIT: changed from Waiter, because of npm conflict]. It doesn't work yet, but I decided to push it anyway. It comes up to a blank screen with errors. This seems like a big victory, however.
Please see docs/busser.html for a docco presentation of comments in the code.
Many thanks to Maurits Lamers for continual help in explaining how garçon and async programming work!
As we all evaluate node-based build tools, I hope busser added to the mix will offer benefits to the community. I will continue its development as a personal exercise whether or not it becomes a serious contender. Other new node.js build tools are described in the Roadmap/Todos section of the busser README.md.
I just wanted to bump this issue and add that alpha-level node build tools have been developed and deployed by @mauritslamers and @geojeff, and are available at https://github.com/sproutcore/build-tools
In order to help this issue forward, it is extremely important that we make a few decisions on whether or how we are going to support sass and slicing under Windows.
For speed, I have been using node-sass, a wrapper around libsass (the C lib parsing sass) and node-canvas.
Especially the latter has quite a few typical *nix based dependencies (cairo, pixman, libpng).
I have been kicking the node-gyp build files around in order to get a binary package that could be distributed as part of the installation package of sproutcore, but so far without success.
While manual compilation under Windows is an option, we have to take into account that most Windows web developers don't have a compiler or compilation environment installed.
The best would perhaps be to have pure-JS alternatives, but these are either very, very slow and not entirely matching sass (stylus), or not implemented at all (slicing).
I would therefore really like the input of the coreteam first, and then the community on how to proceed on this.
I'm hearing that although folks are not willing to give up these features, they're generally willing to do an additional install (with compilation) in order to get them. This supports your idea of having a no-compile, single-command install that supports all systems, with simple instructions available for getting back up to feature parity re: sass and slices.
Closing this issue as the votes are in and the discussion has moved elsewhere.