azimux
ext ex
1 issue, 1 feature request:
I'm having trouble making ext ex work.
From my understanding, ext ex should allow me to export the sub-projects with out the main project.
When I run:
targetdir>ext --workdir /path/to/full/ext/checkout ex
as in the tutorial, I get:
/usr/lib/ruby/1.8/fileutils.rb:264:in rmdir': Directory not empty - modules/apache (Errno::ENOTEMPTY) from /usr/lib/ruby/1.8/fileutils.rb:264:inrmdir'
from /usr/lib/ruby/1.8/fileutils.rb:263:in each' from /usr/lib/ruby/1.8/fileutils.rb:263:inrmdir'
from /usr/lib/ruby/gems/1.8/gems/ext-1.1.0/bin/../lib/externals/extensions/file_utils.rb:21:in rmdir_ie' from /usr/lib/ruby/gems/1.8/gems/ext-1.1.0/bin/../lib/externals/scms/svn_project.rb:12:inco'
from /usr/lib/ruby/gems/1.8/gems/ext-1.1.0/bin/../lib/externals/ext.rb:371:in send' from /usr/lib/ruby/gems/1.8/gems/ext-1.1.0/bin/../lib/externals/ext.rb:371:inco'
from /usr/lib/ruby/gems/1.8/gems/ext-1.1.0/bin/../lib/externals/ext.rb:371:in each' from /usr/lib/ruby/gems/1.8/gems/ext-1.1.0/bin/../lib/externals/ext.rb:371:inco'
from /usr/lib/ruby/gems/1.8/gems/ext-1.1.0/bin/../lib/externals/ext.rb:212:in send' from /usr/lib/ruby/gems/1.8/gems/ext-1.1.0/bin/../lib/externals/ext.rb:212:inrun'
from /usr/lib/ruby/gems/1.8/gems/ext-1.1.0/bin/../lib/externals/ext.rb:211:in chdir' from /usr/lib/ruby/gems/1.8/gems/ext-1.1.0/bin/../lib/externals/ext.rb:211:inrun'
from /usr/lib/ruby/gems/1.8/gems/ext-1.1.0/bin/ext:6
from /usr/bin/ext:19:in `load'
from /usr/bin/ext:19
This is using ruby 1.8 on rhel 6.
module/apache is the first project in by externals puppet repository.
The feature request is to be able to export just one sub-project:
ext --workdir /path/to/workdir ex projectname
Lastly, would you prefer issues, requests to be added here, on lighthouse, or on ruby forge?
Hey malaikah, so in reverse order...
Yeah, I prefer issues here.
Though undocumented,
ext --workdir /path/to/workdir ex projectname
should actually already work (same with co, st, up)
Looks like you can't export that subproject because the directory is not empty. Normally in this use case, the directory doesn't even exist. Ext is willing to delete it if it does exist but is empty for convenience, but gets paranoid if it's not empty (doesn't want to wipe out a potential working directory with important stuff in it.) Is the subproject already checked out there or something? If it's already checked out there (or exported there) then there's no need to use ex/co explicitly. Normally you would use ex when the project was checked /exported out with svn (or cloned with git) instead of with ext checkout. In that situation none of the subprojects exist and so running something to check them out is needed (co) and if you don't want the history you can use (ex.)
Do you happen to know what is in that folder preventing ex from wanting to write there?
Hi,
I think I was misunderstanding the intended use of this function. I had a full ext checkout of my super-project and sub-projects in one place and was wanting to export /just one/ sub-project somewhere else.
Oviously, I can just export the sub-project from git/svn, but as I'm using .externals to describe the connections between projects, I'll need to write something to parse the file to work out what to export.
Thanks anyway.
On 08/08/2012 16:53, Miles Georgi wrote:
Hey malaikah, so in reverse order...
Yeah, I prefer issues here.
Though undocumented,
|ext --workdir /path/to/workdir ex projectname |
should actually already work (same with co, st, up)
Looks like you can't export that subproject because the directory is not empty. Normally in this use case, the directory doesn't even exist. Ext is willing to delete it if it does exist but is empty for convenience, but gets paranoid if it's not empty (doesn't want to wipe out a potential working directory with important stuff in it.) Is the subproject already checked out there or something? If it's already checked out there (or exported there) then there's no need to use ex/co explicitly. Normally you would use ex when the project was checked /exported out with svn (or cloned with git) instead of with ext checkout. In that situation none of the subprojects exist and so running something to check them out is needed (co) and if you don't want the history you can use (ex.)
Do you happen to know what is in that folder preventing ex from wanting to write there?
— Reply to this email directly or view it on GitHub https://github.com/azimux/externals/issues/9#issuecomment-7587925.
Hmmm, interesting, I guess I don't fully understand the use case.
Were you able to come up with a way to accomplish what you were trying to do?
I'm mainly using externals to tie together modules in a puppet project. The whole set of modules ony works as a whole (hence the use of externals) but modules get deployed independtly at different times. The aim with this was to export each module separately (if an export of that version didn't already exist) upon a given trigger. I've changed my workflow around a bit since then, so it's no longer such a useful notion.
Thanks for checking up.
On 02/10/2012 05:44, Miles Georgi wrote:
Hmmm, interesting, I guess I don't fully understand the use case.
Were you able to come up with a way to accomplish what you were trying to do?
— Reply to this email directly or view it on GitHub https://github.com/azimux/externals/issues/9#issuecomment-9058832.