You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On Heroku, applications are deployed to path /app. This path contains the project root of a Catalyst app, for example. The application tries to find the share directory from the project root. (this is a DBIx::Class::Migration (ping @jjn1056) script that uses File::ShareDir::ProjectDistDir, that uses Path::FindDev to do the job.)
However, on Heroku /app is also user's $HOME. Finding share fails, because according to Path::IsDev default heuristics, $HOME can never be a "dev" directory. When traversing up from the application's lib-directory, the search skips over the /app, so /app/share is never considered.
The "positive" heuristics would match (and do, on my local dev env), but IsDev doesn't even consider those after the negative HomeDir match. Maybe this makes sense on some environments, but at least on Heroku this assumption is not correct.
(I can manually override the path in the db migration script, but using the ProjectDistDir is considered the community best practice, and ignoring the /app feels just arbitrary in this case.)
I'm not sure if/how this should be fixed, so I don't have a PR or any other concrete suggestions here. Just pointing out the issue with it. Could you just remove the HomeDir heuristics from the default set, or what is the reasoning behind it?
I think there can be many cases, where user's home really is the "dev" root of some module or app. For example, if I run tests as a dedicated user and checkout the project (to be tested) on that user's $HOME.
The text was updated successfully, but these errors were encountered:
I think there can be many cases, where user's home really is the "dev" root of some module or app. For example, if I run tests as a dedicated user and checkout the project (to be tested) on that user's $HOME.
Sure, this may be the case, but its not so far the dominant case.
The rationale was mostly that it kept false positiving because users had a t/ directory in $HOME or .git or similar.
I personally don't consider ProjectDistDir much of a "Best practice", its a useful tool for certain cases ( which I concede Catalyst apps are one ), but wherever possible, use Test::File::ShareDir::* instead. ( Much more reliable and no side effects at installtime )
Yeah, such is the nature of heuristics though. They'll never be perfect, just percentages of acceptable behaviour if you work in ways they're targeted for.
It will probably be better once I put some harder limits on where FindDev can uplevel.
Much of these heuristics are safe-guards against accidentally marking $HOME/perl5lib/* or $HOME/perl5/perlbrew/* descendants as "development" directories.
Because presently, the uplevel heuristic doesn't consider itself "production" until there is a path between itself and $FSROOT free from positive matching.
Fixing that won't make it perfect, but it should make it more flexible.
On Heroku, applications are deployed to path
/app
. This path contains the project root of a Catalyst app, for example. The application tries to find theshare
directory from the project root. (this is a DBIx::Class::Migration (ping @jjn1056) script that uses File::ShareDir::ProjectDistDir, that uses Path::FindDev to do the job.)However, on Heroku
/app
is also user's $HOME. Findingshare
fails, because according to Path::IsDev default heuristics, $HOME can never be a "dev" directory. When traversing up from the application'slib
-directory, the search skips over the/app
, so/app/share
is never considered.The "positive" heuristics would match (and do, on my local dev env), but IsDev doesn't even consider those after the negative HomeDir match. Maybe this makes sense on some environments, but at least on Heroku this assumption is not correct.
(I can manually override the path in the db migration script, but using the ProjectDistDir is considered the community best practice, and ignoring the
/app
feels just arbitrary in this case.)I'm not sure if/how this should be fixed, so I don't have a PR or any other concrete suggestions here. Just pointing out the issue with it. Could you just remove the HomeDir heuristics from the default set, or what is the reasoning behind it?
I think there can be many cases, where user's home really is the "dev" root of some module or app. For example, if I run tests as a dedicated user and checkout the project (to be tested) on that user's $HOME.
The text was updated successfully, but these errors were encountered: