ext ex

[benpriestman]

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?

[azimux]

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?

[benpriestman]

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
#9 (comment).

[azimux]

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?

[benpriestman]

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
#9 (comment).