I'm wondering about future of AS and Extlib. I heard that these two
should be merged (so extlib will actually die), which makes sense
since these two are sort of similar so we can have just one main
library with Ruby stdlib extensions.
However would this library be suitable for smaller frameworks like
Ramaze or Rango? In current Rails 3 activesupport/lib has 2.8 MB and
52 415 lines (via wc -l) which is more than 20x times bigger than the
whole Rango, so it's not an option for me (as I'm the author of
Rango).
I was talking to Pavel Kunc who currently maintain Merb and it seems
he would like also something significantly smaller.
So what we are suggesting is to keep extlib for these really basic
things like cattr_*, String#to_snakecase etc and everything else put
into activesupport which will be builded on top of extlib.
So everyone should be happy:
1) There would be just one extensions library (well, one small and
one big, but the point is it's still DRY)
2) Rails will have AS, so Rails will be happy and smaller frameworks
will have extlib, so they could be happy as well.
In case you guys won't like this idea, there would be need for smaller
extension library, so someone (probably me) will write it and code
duplication, welcome back.
We spent a bunch of time making ActiveSupport more cherry-pickable. If there are still clumps that aren’t fine-grained enough for your needs (I did some work to make the inflector a bit more fine-grained), please let me know (I’d consider it a bug).
Are you otherwise concerned about the disk space occupied by ActiveSupport? Please explain a bit more exactly what your requirements are that prevent the use of ActiveSupport in Rails 3.
Hi Yehuda, I'm not sure if you get me right, AS is fine for Rails 3,
but we are more interested in something more suitable for smaller
frameworks, so we would very welcome to have extlib with basic things
and as with the rest.
Because I don't want to spent ages when I'm reading source code just
scrolling down in dir browser buffer and I don't care about 95% stuff
included in AS. Because I want less things in my git repository,
faster deploys etc etc. AS is just not what I'm going to use when I
actually need just a few tiny methods to standard Ruby, that's it.
So far, from my understanding, what you've said is that you want to use some parts of ActiveSupport, but you don't want to use the entire ActiveSupport "collection". It would be helpful to us if you could name the parts that you are wanting to use and we'll set you on the right path.
What you need from ActiveSupport will of course be different from what other people need from ActiveSupport. I don't think it is up to Rails Core to go through and rip out what you deem as important components; It's already neatly sectioned off.
If you want only parts of ActiveSupport you're going to have require them yourself, and a bit more. Take for example if you wanted to require the extensions to the Array class you need to also require the object extensions too, since some methods require the method "returning" from it.
Just to be clear, if there are cases where useful functionality of ActiveSupport is hidden behind dependencies that aren’t obviously necessary, I personally would consider that a bug, and improve the collection to make it easier to pick the parts that are needed.
However, I haven’t seen any specific requests, or reports of dependency problems, so I don’t know what to fix. All I know is that we’ve spent considerable time making ActiveSupport suitable for smaller projects that don’t want to pull the entire thing in (with the base requirement consuming virtually no resources).
I’d like to hear specific, concrete problems. I assure you I will take them seriously.
From what I could see, there wasn’t an “easy” way to require I18n, such
as in my example of requiring the array extensions. Not too sure if
this is important, but having a require ‘activesupport/i18n’ would be
handy.
So far, from my understanding, what you've said is that you want to use
some parts of ActiveSupport, but you don't want to use the entire
ActiveSupport "collection". It would be helpful to us if you could name
the parts that you are wanting to use and we'll set you on the right path.
What you need from ActiveSupport will of course be different from what
other people need from ActiveSupport. I don't think it is up to Rails
Core to go through and rip out what you deem as important components;
It's already neatly sectioned off.
If you want only parts of ActiveSupport you're going to have require
them yourself, and a bit more. Take for example if you wanted to require
the extensions to the Array class you need to also require the object
extensions too, since some methods require the method "returning" from it.
Is there a specific reason why each pice won't require its
dependencies? I mean, if core_ext/array needs core_ext/object for
Object#returning, why doesn't it require at the top of the file?
That would certainly make it easier on whoever wants to just use
in_groups_of, since he doesn't have to go through the NoMethodErrors
(or with any luck, undefined constants, which means it breaks on
"compile" time)
That’s PRECISELY what we’ve been doing. If there are cases of dependencies that are not appropriately required, please file a bug so we can get it fixed.
Jakub's concern does indeed seem to be disk space. Maybe a solution would be to develop a way to to easily redistribute parts of AS, for those developing other frameworks that only require small bits of it.
That's PRECISELY what we've been doing. If there are cases of dependencies
that are not appropriately required, please file a bug so we can get it
fixed.
Ah, sorry, I thought that, but Ryan's message confused me
First of all thanks all you guys for useful discussions.
Yehuda wants some concrete things I don't like on AS, so:
1) There is no reason why AS should have an executables. bin/
generate_tables is just messing my $PATH. It matter especially in
bundled environment where I want to have my bin/ clean.
2) I don't like that there is a lot of stuff which should be in
separate gems. For example multibyte, cache, backtrace cleaner ...
basically in my opinion in AS should be just core_exts and maybe some
other generic things like callbacks. I believe this is not very good
design.
3) Why is locale/en.yml in lib and therefore is de facto loadable (via
load 'active_support/locale/en.yml')?
1) & 3) isn't so important, the most important for me is definitely
2). In Merb, there was huge amount of gems, Rails 2 are too
monolithic, it would be nice to come with some reasonable design
finally I would really put some less generic stuff into separate
gems.
