<ddfreyne>
I need nanoc-core for the gem to be built (due to the require statement)
<ddfreyne>
But the dependency on nanoc-core is only declared afterwards.
<ddfreyne>
It seems to me that this is not possible with Rubygems
<bobthecow>
honestly, manually bumping one value in each gemfile isn't the end of the world.
<bobthecow>
and it makes for an artifact that you can commit to the repo to let people know something changed.
<ddfreyne>
Yeah, makes sense
<bobthecow>
actually, at that point it might make sense to have a VERSION for each gem.
<bobthecow>
then you could do s.version = Nanoc::VERSION and s.add_dependency('nanoc-core', "= #{Nanoc::VERSION}"
<bobthecow>
hmm.
<bobthecow>
rails solves it by having both gems in the same repo.
<ddfreyne>
Yeah, meh
<bobthecow>
so activerecord requires ../../RAILS_VERSION
<ddfreyne>
Also, Nanoc::VERSION is declared by nanoc-core already :<
<bobthecow>
you know, it might not be problematic to have nanoc, nanoc-cli and nanoc-core in the same repo.
<bobthecow>
that would guarantee that things are updated at the same time, would give you a relative place to require a version file, and would mean you could tag in one go.
<bobthecow>
but have three different folders, with three different gemspecs.
<ddfreyne>
Hmm, that is a possibility. I'm not sure I like it that much though
<ddfreyne>
A alternative I was thinking about was a nanoc-version submodule
<ddfreyne>
With one file, VERSION, containing the version number
<ddfreyne>
It feels wrong to move away from the one-gem-per-repo or one-project-per-repo idea
<jachymko>
i know next to nothing about ruby and its conventions, but i'd find it reasonable to either have the three gems in one repo and version them together
<jachymko>
or have them in separate repos and version them independently
<jachymko>
which is obviously more work
<jachymko>
and the question is whether it has any advantages
<ddfreyne>
I'm favouring the idea of having a version submodule at the moment.
<bobthecow>
ddfreyne: i don't like that.
<jachymko>
that seems a bit over-engineered to me. another moving part and the core projects are still tightly coupled--altough in three repos, so it'll be more pain to release a version
<bobthecow>
because you'll still have to bump and commit the submodule.
<bobthecow>
you might as well be bumping a file.
<jachymko>
yep
<bobthecow>
i'm really leaning toward the rails-style multiple projects in one repo.
<bobthecow>
just for nanoc/core/cli
<bobthecow>
because those are the three that are tightly coupled.
<ddfreyne>
nanoc/nanoc-core at least. Not entirely sure about cli
<bobthecow>
that way the version is stored in a single file, bumped all at the same time, and committed and tagged all at the same time.
<bobthecow>
i think cli too, for now.
<bobthecow>
i don't see there being a really viable non-cli interface until 5.x.
<bobthecow>
but maybe that's just the realist (pessimist?) in me ;)
<ddfreyne>
One of the goals of nanoc 4.x is to make it easier to write other interfaces
<ddfreyne>
So a nanoc-web should be possible :)
<bobthecow>
right.
<bobthecow>
which means it'll be right in time for 5.x
<ddfreyne>
haha
<jachymko>
so if the goal is to remove the tight coupling, why not version them independent of each other?
<bobthecow>
jachymko: because what number should come out when you say `nanoc --version`?
<ddfreyne>
jachymko: I'm inclined to version nanoc-cli independently, yes
<jachymko>
nanoc: 4.0
<jachymko>
nanoc-cli: 4.5
<bobthecow>
ugh.
<bobthecow>
really?
<ddfreyne>
nanoc --version could print something like "nanoc 4.0.0 (nanoc-cli 1.0.1)"
<bobthecow>
rails has 8 gems in their main repo, all versioned in lockstep.
<ddfreyne>
bobthecow: One drawback is that this is hard to use with bundler's :git => stuff
<bobthecow>
nope nope.
<bobthecow>
wait. maybe.
<bobthecow>
doesn't it offer a way to specify what the gemfile is?
<ddfreyne>
No
<ddfreyne>
You can specificy a :ref, :branch or :tag
<bobthecow>
git 'git://github.com/rails/rails.git' do gem 'railties' gem 'action_pack' gem 'active_model' end
<bobthecow>
they already thought of that ;)
<ddfreyne>
Ahh
<ddfreyne>
I need to think about this some more.
<ddfreyne>
I would very much like to avoid the submodule solution because I do not like submodules :(
<jachymko>
submodules aren't that bad, but a submodule only to share a version number, that's just wrong :)
<jachymko>
it really depends if you want to position nanoc-core more as a library. if it's a library and nanoc-cli or a future nanoc-web are apps built on top of that library, then there should be separate repositories and separate versions. nanoc-cli 1.0 can support nanoc 4.0.0-4.999.999
<jachymko>
if you want to release one "nanoc" as a product, with nanoc-cli, -core and -web as mere subprojects, then it would make sense to just have a single repository with more gems inside, versioned in lockstep
<jachymko>
and you dont need to worry yourself about compatibility, because nanoc-cli and nanoc-werb 4.3.1 will only support nanoc-core 4.3.1
vivien_ has joined #nanoc
<jachymko>
you'd still need to maintain stable api for the -powerpack etc. projects
<jachymko>
so perhaps the library approach makes more sense. but it is more pain in the short run
<VitamineD>
I get conflicts when pulling nanoc-core ? I don't think I made local changes, were there dubious thing done to git ?
<VitamineD>
I'm at e86b3dc
<VitamineD>
yeah, looks like the repo was recreated from scratch
vivien_ has left #nanoc [#nanoc]
whk has joined #nanoc
<guardian>
o/
<ddfreyne>
VitamineD: Yes, the history was cut
<ddfreyne>
VitamineD: What changes did you have locally?
<VitamineD>
none, I just had the old history up to "Remove cri as runtime dependency"
<ddfreyne>
ok
<bobthecow>
VitamineD: when something like that comes up, and you don't have any local changes, just `git reset --hard origin/branchname`
<VitamineD>
hmm true
<VitamineD>
that moves the master pointer, right ?
<bobthecow>
yeah. it changes your local master pointer to be whatever origin/branchname's pointer is.
<bobthecow>
then the --hard part does a git checkout
louquillio has quit [Remote host closed the connection]
alerante has joined #nanoc
alerante has quit [Ping timeout: 245 seconds]
alerante has joined #nanoc
number-six has quit [Ping timeout: 246 seconds]
jaspervdj has quit [Ping timeout: 246 seconds]
<guardian>
re
alerante_ has joined #nanoc
alerante has quit [Ping timeout: 268 seconds]
alerante_ has quit [Remote host closed the connection]