FAQ
In Catalyst::Utils::home
is the following requirement documented anywhere?
# only return the dir if it has a Makefile.PL or Build.PL
if (-f $home->file("Makefile.PL") or -f $home->file("Build.PL"))

Cheers,
jec

Search Discussions

  • Matt S Trout at May 28, 2007 at 9:43 pm

    On Mon, May 28, 2007 at 12:11:54PM -0700, Jeff Chimene wrote:
    In Catalyst::Utils::home
    is the following requirement documented anywhere?
    # only return the dir if it has a Makefile.PL or Build.PL
    if (-f $home->file("Makefile.PL") or -f $home->file("Build.PL"))
    It's only required if you haven't installed the app - it's how Catalyst tells
    you're still running out of a development directory.

    --
    Matt S Trout Need help with your Catalyst or DBIx::Class project?
    Technical Director Want a managed development or deployment platform?
    Shadowcat Systems Ltd. Contact mst (at) shadowcatsystems.co.uk for a quote
    http://chainsawblues.vox.com/ http://www.shadowcatsystems.co.uk/
  • Jeff Chimene at May 28, 2007 at 10:00 pm

    Matt S Trout wrote:
    On Mon, May 28, 2007 at 12:11:54PM -0700, Jeff Chimene wrote:

    In Catalyst::Utils::home
    is the following requirement documented anywhere?
    # only return the dir if it has a Makefile.PL or Build.PL
    if (-f $home->file("Makefile.PL") or -f $home->file("Build.PL"))
    It's only required if you haven't installed the app - it's how Catalyst tells
    you're still running out of a development directory.
    What does "installed the app..." mean?

    The use case is that I copied all files in the HOME & descendants (but
    Makefile.PL and Build.PL) to the production machine. Two hours later, I
    figured out why the app wouldn't start. Hence this topic.

    Pointers to documentation would be appreciated.

    Cheers,
    jec

    P.S. I originally sent this app to the server via Makefile.PL
    constructing a tarball. The disadvantage is that this is a crappy way to
    send .PATCH files; which process is how I'd like to move from
    development to production in this Brave New World after the initial
    deployment. Of course, it turns out that the production machine doesn't
    have /usr/bin/patch, but that's another issue.
  • Matt S Trout at May 28, 2007 at 10:41 pm

    On Mon, May 28, 2007 at 02:00:13PM -0700, Jeff Chimene wrote:
    Matt S Trout wrote:
    On Mon, May 28, 2007 at 12:11:54PM -0700, Jeff Chimene wrote:

    In Catalyst::Utils::home
    is the following requirement documented anywhere?
    # only return the dir if it has a Makefile.PL or Build.PL
    if (-f $home->file("Makefile.PL") or -f $home->file("Build.PL"))
    It's only required if you haven't installed the app - it's how Catalyst tells
    you're still running out of a development directory.
    What does "installed the app..." mean?
    perl Makefile.PL; make install
    The use case is that I copied all files in the HOME & descendants (but
    Makefile.PL and Build.PL) to the production machine. Two hours later, I
    figured out why the app wouldn't start. Hence this topic.
    How do you verify your production machine has any new dependencies without
    Makefile.PL ?
    P.S. I originally sent this app to the server via Makefile.PL
    constructing a tarball. The disadvantage is that this is a crappy way to
    send .PATCH files; which process is how I'd like to move from
    development to production in this Brave New World after the initial
    deployment. Of course, it turns out that the production machine doesn't
    have /usr/bin/patch, but that's another issue.
    That's a really, spectacularly bad idea since it means your deployment process
    isn't repeatable, which makes it a crappy deployment process :)

    --
    Matt S Trout Need help with your Catalyst or DBIx::Class project?
    Technical Director Want a managed development or deployment platform?
    Shadowcat Systems Ltd. Contact mst (at) shadowcatsystems.co.uk for a quote
    http://chainsawblues.vox.com/ http://www.shadowcatsystems.co.uk/
  • Jeff Chimene at May 29, 2007 at 1:20 am

    Matt S Trout wrote:
    On Mon, May 28, 2007 at 02:00:13PM -0700, Jeff Chimene wrote:

    Matt S Trout wrote:
    On Mon, May 28, 2007 at 12:11:54PM -0700, Jeff Chimene wrote:

    In Catalyst::Utils::home
    is the following requirement documented anywhere?
    # only return the dir if it has a Makefile.PL or Build.PL
    if (-f $home->file("Makefile.PL") or -f $home->file("Build.PL"))
    It's only required if you haven't installed the app - it's how Catalyst tells
    you're still running out of a development directory.

    What does "installed the app..." mean?
    perl Makefile.PL; make install
    OK. I hadn't considered putting the Perl files into the shared
    directories on the server. I know there are settings that one can enable
    to force the installation to a user-specific directory tree. Since I'm
    chasing installation problems w/r/t/ configuration differences between
    the development & production machines, this is one more item to learn
    that only incrementally adds value.
    The use case is that I copied all files in the HOME & descendants (but
    Makefile.PL and Build.PL) to the production machine. Two hours later, I
    figured out why the app wouldn't start. Hence this topic.
    How do you verify your production machine has any new dependencies without
    Makefile.PL ?
    It isn't that complicated a deployment.
    P.S. I originally sent this app to the server via Makefile.PL
    constructing a tarball. The disadvantage is that this is a crappy way to
    send .PATCH files; which process is how I'd like to move from
    development to production in this Brave New World after the initial
    deployment. Of course, it turns out that the production machine doesn't
    have /usr/bin/patch, but that's another issue.
    That's a really, spectacularly bad idea since it means your deployment process
    isn't repeatable, which makes it a crappy deployment process :)
    You aren't the arbiter of what's good or bad. Please just answer my
    questions, reserving your opinions for beer-thirty.

    Cheers,
    jec
  • Matt S Trout at May 29, 2007 at 2:05 am

    On Mon, May 28, 2007 at 05:20:04PM -0700, Jeff Chimene wrote:
    Matt S Trout wrote:
    On Mon, May 28, 2007 at 02:00:13PM -0700, Jeff Chimene wrote:
    P.S. I originally sent this app to the server via Makefile.PL
    constructing a tarball. The disadvantage is that this is a crappy way to
    send .PATCH files; which process is how I'd like to move from
    development to production in this Brave New World after the initial
    deployment. Of course, it turns out that the production machine doesn't
    have /usr/bin/patch, but that's another issue.
    That's a really, spectacularly bad idea since it means your deployment process
    isn't repeatable, which makes it a crappy deployment process :)
    You aren't the arbiter of what's good or bad. Please just answer my
    questions, reserving your opinions for beer-thirty.
    No, but I do have a fair bit of experience deploying software, and I'd strongly
    recommend against any deployment process that isn't as simple and repeatable
    as possible.

    Basically, an idempotent deployment process is almost always preferable where
    possible since it means you don't have to consider ordering problems - if
    a deployment fails part-way through you can simply re-run it, and if a system
    is "out of the loop" for a couple deployments (due to hardware failure, for
    e.g) you can still treat it identically to a machine on release N-1.

    I'm not on here to 'just answer your questions', I'm on here to be part of a
    community discussion list where we not only try and help people solve problems
    but to solve problems in -good- ways, especially since this list is archived
    and people use archive searches as a way to find ideas and implementation
    techniques - and as a member of the core team I try and make clear what I
    consider wise and unwise since I'm aware my choices often influence those
    of other Catalyst users. You are, of course, welcome to disagree with, argue
    against or ignore entirely any opinion I express but that's not going to stop
    me expressing them :)

    --
    Matt S Trout Need help with your Catalyst or DBIx::Class project?
    Technical Director Want a managed development or deployment platform?
    Shadowcat Systems Ltd. Contact mst (at) shadowcatsystems.co.uk for a quote
    http://chainsawblues.vox.com/ http://www.shadowcatsystems.co.uk/
  • Jeff Chimene at May 29, 2007 at 2:25 am

    Matt S Trout wrote:
    On Mon, May 28, 2007 at 05:20:04PM -0700, Jeff Chimene wrote:

    Matt S Trout wrote:
    On Mon, May 28, 2007 at 02:00:13PM -0700, Jeff Chimene wrote:

    P.S. I originally sent this app to the server via Makefile.PL
    constructing a tarball. The disadvantage is that this is a crappy way to
    send .PATCH files; which process is how I'd like to move from
    development to production in this Brave New World after the initial
    deployment. Of course, it turns out that the production machine doesn't
    have /usr/bin/patch, but that's another issue.
    That's a really, spectacularly bad idea since it means your deployment process
    isn't repeatable, which makes it a crappy deployment process :)
    You aren't the arbiter of what's good or bad. Please just answer my
    questions, reserving your opinions for beer-thirty.
    No, but I do have a fair bit of experience deploying software, and I'd strongly
    recommend against any deployment process that isn't as simple and repeatable
    as possible.

    Basically, an idempotent deployment process is almost always preferable where
    possible since it means you don't have to consider ordering problems - if
    a deployment fails part-way through you can simply re-run it, and if a system
    is "out of the loop" for a couple deployments (due to hardware failure, for
    e.g) you can still treat it identically to a machine on release N-1.

    I'm not on here to 'just answer your questions', I'm on here to be part of a
    community discussion list where we not only try and help people solve problems
    but to solve problems in -good- ways, especially since this list is archived
    and people use archive searches as a way to find ideas and implementation
    techniques - and as a member of the core team I try and make clear what I
    consider wise and unwise since I'm aware my choices often influence those
    of other Catalyst users. You are, of course, welcome to disagree with, argue
    against or ignore entirely any opinion I express but that's not going to stop
    me expressing them :)
    I don't have time to argue with you. You are not the arbiter of good or
    bad development/deployment practices. I certainly will not be hiring you
    for any projects.

    Cheers,
    jec
  • Jonathan Rockway at May 29, 2007 at 8:25 am

    On Monday 28 May 2007 08:25:05 pm Jeff Chimene wrote:
    I don't have time to argue with you. You are not the arbiter of good or
    bad development/deployment practices. I certainly will not be hiring you
    for any projects.
    You are the arbiter of bad development/deployment practices. To others
    reading this thread without a vested interest:

    * use Makefile.PL
    * keep it updated
    * deploy with tar or PAR

    That is all.

    BTW, you're aware that Matt wrote a large portion of Catalyst and DBIx::Class,
    right? He knows what he's talking about. I wouldn't dismiss his advice so
    quickly. You should be thanking him for suggesting a correction in your
    processes before it bit you in the ass. Most of the other readers of the
    list had the same idea, but he decided to actually bring it up. That's
    pretty nice of him.

    And finally, don't take offense to being called out on a mailing list. Would
    you rather correct your bad idea on a mailing list where nobody cares about
    you, or would you rather lose your job and clients when your technique fucks
    up an important production push? This is just a mailing list... use it as an
    opportunity to learn; don't get offended.

    OK, I'm done now. Gnite :)

    Regards,
    Jonathan Rockway

    --
    package JAPH;use Catalyst qw/-Debug/;($;=JAPH)->config(name => do {
    $,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
    ";$;"]->[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;->setup;
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 307 bytes
    Desc: not available
    Url : http://lists.scsys.co.uk/pipermail/catalyst/attachments/20070529/79a0a973/attachment.pgp
  • Jeff Chimene at May 29, 2007 at 4:11 am

    Matt S Trout wrote:
    On Mon, May 28, 2007 at 02:00:13PM -0700, Jeff Chimene wrote:

    Matt S Trout wrote:
    On Mon, May 28, 2007 at 12:11:54PM -0700, Jeff Chimene wrote:

    In Catalyst::Utils::home
    is the following requirement documented anywhere?
    # only return the dir if it has a Makefile.PL or Build.PL
    if (-f $home->file("Makefile.PL") or -f $home->file("Build.PL"))
    It's only required if you haven't installed the app - it's how Catalyst tells
    you're still running out of a development directory.

    What does "installed the app..." mean?
    perl Makefile.PL; make install

    The use case is that I copied all files in the HOME & descendants (but
    Makefile.PL and Build.PL) to the production machine. Two hours later, I
    figured out why the app wouldn't start. Hence this topic.
    How do you verify your production machine has any new dependencies without
    Makefile.PL ?

    P.S. I originally sent this app to the server via Makefile.PL
    constructing a tarball. The disadvantage is that this is a crappy way to
    send .PATCH files; which process is how I'd like to move from
    development to production in this Brave New World after the initial
    deployment. Of course, it turns out that the production machine doesn't
    have /usr/bin/patch, but that's another issue.
    That's a really, spectacularly bad idea since it means your deployment process
    isn't repeatable, which makes it a crappy deployment process :)
    Great. How does one move the root/ directory? It gets into the .tar
    file, but isn't deployed on the production server.
  • Matt S Trout at May 29, 2007 at 1:22 pm

    On Mon, May 28, 2007 at 08:11:19PM -0700, Jeff Chimene wrote:
    Great. How does one move the root/ directory? It gets into the .tar
    file, but isn't deployed on the production server.
    Assuming Catalyst::Devel is installed on the server you did the make dist
    on, the 'catalyst()' line in your Makefile.PL should invoke the bundled
    inc/Module/Install/Catalyst.pm such that the root/ directory will go
    into site_perl along with everything else; then at runtime Catalyst will
    use File::ShareDir to find this directory again, meaning MyApp->path_to
    will resolve paths to in there.

    Assuming that's -not- what you're seeing, can you check your inc/ to make
    sure the Catalyst Module::Install extension's in there and then maybe use
    'make -n install' or a find on site_perl to see if your root/ has just
    been installed somewhere you didn't expect.

    If that doesn't bring enlightenment, tell us what you -did- see when you
    checked the things I just suggested and with a bit of luck we'll be able to
    figure out what's not going to plan.

    --
    Matt S Trout Need help with your Catalyst or DBIx::Class project?
    Technical Director Want a managed development or deployment platform?
    Shadowcat Systems Ltd. Contact mst (at) shadowcatsystems.co.uk for a quote
    http://chainsawblues.vox.com/ http://www.shadowcatsystems.co.uk/
  • Jeff Chimene at May 29, 2007 at 4:14 pm

    Matt S Trout wrote:
    On Mon, May 28, 2007 at 08:11:19PM -0700, Jeff Chimene wrote:

    Great. How does one move the root/ directory? It gets into the .tar
    file, but isn't deployed on the production server.
    Assuming Catalyst::Devel is installed on the server you did the make dist
    on, the 'catalyst()' line in your Makefile.PL should invoke the bundled
    inc/Module/Install/Catalyst.pm such that the root/ directory will go
    into site_perl along with everything else; then at runtime Catalyst will
    use File::ShareDir to find this directory again, meaning MyApp->path_to
    will resolve paths to in there.

    Assuming that's -not- what you're seeing, can you check your inc/ to make
    sure the Catalyst Module::Install extension's in there and then maybe use
    'make -n install' or a find on site_perl to see if your root/ has just
    been installed somewhere you didn't expect.
    Make::Install is there:
    $ ls -R inc
    inc:
    Module

    inc/Module:
    AutoInstall.pm Install Install.pm

    inc/Module/Install:
    AutoInstall.pm Can.pm Include.pm Metadata.pm Win32.pm
    Base.pm Fetch.pm Makefile.pm Scripts.pm WriteAll.pm

    make -n install shows:
    /usr/bin/perl "-Iinc" "-MExtUtils::Command" -e mkpath
    /usr/lib/perl5/5.8.3/i386-linux-thread-multi
    /usr/bin/perl "-Iinc" "-MExtUtils::Command::MM" -e perllocal_install \
    "Module" "aic" \
    "installed into" "/usr/lib/perl5/site_perl/5.8.3" \
    LINKTYPE "dynamic" \
    VERSION "0.01" \
    EXE_FILES "script/aic_cgi.pl script/aic_create.pl
    script/aic_fastcgi.pl script/aic_server.pl script/aic_test.pl" \
    /usr/lib/perl5/5.8.3/i386-linux-thread-multi/perllocal.pod
    If that doesn't bring enlightenment, tell us what you -did- see when you
    checked the things I just suggested and with a bit of luck we'll be able to
    figure out what's not going to plan.
    Thanks for your assistance.

    This probably has something to do with the newly discovered requirement
    to define CATALYST_HOME in the package. For now, I've put it into the
    aic_cgi.pl script.

    As badly as things have gone with this technique as well as the
    responses I've received from you and Jonathan, I will avoid asking the
    list for further advice.

    Cheers,
    jec
  • Chisel Wright at May 29, 2007 at 4:33 pm

    On Tue, May 29, 2007 at 08:14:17AM -0700, Jeff Chimene wrote:
    As badly as things have gone with this technique as well as the
    responses I've received from you and Jonathan, I will avoid asking the
    list for further advice.
    Shame, this list is an excellent resource. I reckon in the long run
    you'll make things more difficult for yourself. Still, TMTOWTDI


    --
    Chisel Wright
    e: chisel@herlpacker.co.uk
    w: http://www.herlpacker.co.uk/

    I even make myself laugh sometimes...
  • Matt S Trout at May 29, 2007 at 4:36 pm

    On Tue, May 29, 2007 at 08:14:17AM -0700, Jeff Chimene wrote:
    Matt S Trout wrote:
    On Mon, May 28, 2007 at 08:11:19PM -0700, Jeff Chimene wrote:

    Great. How does one move the root/ directory? It gets into the .tar
    file, but isn't deployed on the production server.
    Assuming Catalyst::Devel is installed on the server you did the make dist
    on, the 'catalyst()' line in your Makefile.PL should invoke the bundled
    inc/Module/Install/Catalyst.pm such that the root/ directory will go
    into site_perl along with everything else; then at runtime Catalyst will
    use File::ShareDir to find this directory again, meaning MyApp->path_to
    will resolve paths to in there.

    Assuming that's -not- what you're seeing, can you check your inc/ to make
    sure the Catalyst Module::Install extension's in there and then maybe use
    'make -n install' or a find on site_perl to see if your root/ has just
    been installed somewhere you didn't expect.
    Make::Install is there:
    $ ls -R inc
    inc:
    Module

    inc/Module:
    AutoInstall.pm Install Install.pm

    inc/Module/Install:
    AutoInstall.pm Can.pm Include.pm Metadata.pm Win32.pm
    Base.pm Fetch.pm Makefile.pm Scripts.pm WriteAll.pm
    Bingo. No Module::Install::Catalyst, as I suspected.

    Make sure the machine you're building the dist on has Catalyst::Devel installed,
    then do

    rm -rf inc/
    perl Makefile.PL
    make manifest
    make dist

    That should get you a dist with inc/Module/Install/Catalyst.pm, which should
    work fine.
    Thanks for your assistance.

    This probably has something to do with the newly discovered requirement
    to define CATALYST_HOME in the package. For now, I've put it into the
    aic_cgi.pl script.
    With the above fix, you won't need to define anything.
    As badly as things have gone with this technique as well as the
    responses I've received from you and Jonathan, I will avoid asking the
    list for further advice.
    Your only issue with this technique was building the inc/ + dist on a system
    that wasn't set up as a catalyst development system (i.e. Catalyst::Devel
    installed) - and I did suggest that that was the problem in my last e-mail.

    While it would probable be better if Module::Install provided a warning
    about not finding a handler for the catalyst() line, it's not a problem
    people normally run into since ::Devel is something you'd always have installed
    on your development system since that's required for script/myapp_create.pl
    and catalyst.pl to work.

    I'm sorry you feel things have gone badly and wish you the best of luck with
    your use of Catalyst in the future, whether you choose to post here again or
    not.

    --
    Matt S Trout Need help with your Catalyst or DBIx::Class project?
    Technical Director Want a managed development or deployment platform?
    Shadowcat Systems Ltd. Contact mst (at) shadowcatsystems.co.uk for a quote
    http://chainsawblues.vox.com/ http://www.shadowcatsystems.co.uk/
  • Tatsuhiko Miyagawa at May 29, 2007 at 4:40 pm
    I agree this should be documented somewhere, since I was falling into
    the same problem with my toy app and ended up 'touch'ing the dummy
    Makefile.PL.

    For our work stuff, we removed Makefile.PL as well but we're setting
    CATALYST_HOME environment variable from our app launching script.
    On 5/28/07, Jeff Chimene wrote:
    In Catalyst::Utils::home
    is the following requirement documented anywhere?
    # only return the dir if it has a Makefile.PL or Build.PL
    if (-f $home->file("Makefile.PL") or -f $home->file("Build.PL"))

    Cheers,
    jec


    _______________________________________________
    List: Catalyst@lists.rawmode.org
    Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
    Dev site: http://dev.catalyst.perl.org/

    --
    Tatsuhiko Miyagawa

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedMay 28, '07 at 8:11p
activeMay 29, '07 at 4:40p
posts14
users5
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2022 Grokbase