What I want is nothing less than a single, coherent guide to project management: How to organize files in my local project folder and how to get them from there to everywhere else they need to go.

You can make this as easy as you want, or as complicated as you want. You have been told previously to just take an existing distribution and modify it to suit your project. But you seem to want something else, yet haven't told us why. So you seem to search something more complicated.

So, the reply I seek contains a single reference to a comprehensive work on the overall topic.

It doesn't exist beyond what has been pointed out to you already.

I don't ask, How do you do it? I ask, How did you learn?

By looking at how others do it, and mimicing it, until I came up with a set of ways that worked my process.

This is one time I don't want a toolbox; I want a running automobile.

You're asking for far more than that.

To stick with your anology--which just happens to be one of my favorites--what you are asking for is:

A stylish 18-wheel, 7-seat, drop-head, hybrid, supercar. With F1 performance, Prius economy, Peterbilt carrying capacity, Porsche cache and Spyder exclusivity.

And what you'll get if you try to meet that spec is a duck-billed camel with two legs, four wings and a blow hole.

Even if you succeeded in evolving your perfect structure anytime soon--which is unlikely as evolution takes time--you'd get something that would work for one particular type of project, and no other. And in the process you'd set yourself up for for ongoing pain every time you had to work within the constraints of another's "perfect system"; or any pre-existing system.

In an ideal world, there would be a one-size fits all, perfect development environment. But the world is far from perfect.

Please pardon my stating the obvious, but it seems that there are only two possible categories of answers here: either you do it the way everyone else does - i.e., standard project management techniques appropriate for the level at which you do your work - or you do things your own way and invent your own methods. Following your own path is great stuff, but there are always costs to doing so, many of them unpredictable or at least invisible from the point where you diverge from standard practice. Take it from a guy who's climbed a lot of strange mountains and sailed many a mile of stormy seas, both literal and figurative, for the last few decades: when you choose to be different, you need to be very, very careful about picking your battles. E.g. - sure, you like doing this your own way - but what are you willing to pay for it in time, effort, money, and trouble? Figure out that limit, and revisit that decision once in a while.

What I want is nothing less than a single, coherent guide to project management: How to organize files in my local project folder and how to get them from there to everywhere else they need to go.

Expanding on and continuing what I've said above, I don't think that the answer you're looking for exists - at least not in any way that can be conveyed in a post (or even in a thick book); the situation is complex enough, and constrained by enough of your personal choices that the solution is going to be primarily social rather than technical.

You could learn project management techniques - there are academic courses available for this - and design your own system (and continue to revise it until it's exactly what you want); this is perhaps the most scalable solution. Conversely, you could hire an experienced project manager (heck, there's probably tons of them starving at Dice.com) on a consulting basis, feed them your list of requirements, and ask them to design a system for you. Since you won't be the expert in the situation, *listen* to their advice about the pitfalls if you go this route; I understand that you want to do things your own way, but there are times when certain techniques are just B.A.D. (Broken As Designed) from word 'go', and need to be done away with.

In any case, as one explorer to another, I wish you the best of luck. :)

A single reference? here you go: KISS

For the record: I use the Eclipse IDE. It's not perfect but I got used to it. It can be extended with plugins. There are tons of available plugins, see for example Eclipse plugins, and it's not too difficult to develop your own plugins. An added bonus is that it's platform independent (I used it on Windows and Linux and currently on the Mac) and that you can use it for basically any programming language. Whatever tools and approach you use the keyword is consistency.

It seems you are looking for perfection... Have no fear of perfection - you'll never reach it. Salvador Dali

It just seems to me that you want the community to ratify the approach that you have elected to take, when the simple answer is: TMTOWTDI.   Like everyone who has trod this path before or after you, you will strike upon an approach that works well for you and for the project ... and everyone who follows you (after you get smooshed by a camel driving a bread-truck) will look upon it with great puzzlement and say, “what the hell ...?”

It so happens that certain approaches have gained favor over time, and each one has its detractors, too.   No one says that you must follow any of them; nor that any of them are right for you, for this project, right now.   This is a craft, not an art.

This is how you do it:

Do the absolute least that you possibly can. If that doesn't quite solve your problem, do a little more.

Perhaps you've missed the point of programming in Perl - easy things are easy, hard things are possible. If you want a system that's going to hold your hand through every conceivable little thing and think for you - then switch to C# and use Visual Studio. Everything just clicks together right out of the box and you don't have to think. Of course .Net + Visual Studio has its own problems (being from Microsoft and only runs on Windows being the root of them).

There is no ONE TRUE WAY to do anything. You have to adapt to the situation at hand.

If you are worried about doing things too difficult for others to understand, then try doing what everyone else does:

• Use Git/SVN/CVS/whatever. Don't use something you invented.
• Use normal folder structures (~/projects/someproject/lib etc t sbin whatever) is fine.
• Perl has this great module installer thingy called "CPAN" - you may have heard of it. Don't install modules in your application's directory, as they may be out of date.
• Use the simplest thing that could possibly work! Every additional requirement is just another flaming hoop you jump through. No hoops = no jumping.
• Look at Padre - it's a large project and has many dependencies. It also installs quite nicely. Look at the project structure - it has many developers and everyone seems to get along just fine working together. It is a success - do what they are doing!

True experts do not “starve.”

They always have more work than they can do.   And, people wait in line to have them do it (or direct it).

And I will also opine this:   in thirty years of doing this crazy computer-programming thing, I have never in my life seen quite such a company of bona fide experts, “all in one place,” as is found right here.   And I do not presume to count myself among their number.

++ however there were a lot of out of work PhDs around when I was a kid in rural New Mexico; the proximity of the Sandia and Los Alamos National labs. LSD was $4 a tab, at most, because some of the unemployed were chemists.

Expertise can't always overcome personal choices or quirks. An expert with an inconvenient personality tick or unusually strong ethics will have a much harder time finding work. One easy example: Deciding against working for the US government as a conscientious position can cut a huge swath right through the available jobs. Hell, your very expertise can count against you if you're engaged in a field that is highly regulated or political. People who know exactly what they are doing can be a burden or even a legal liability in those situations.

(I'm pro-expertise and highly pro-work, I just has to calls 'em like I sees 'em.)

Your Mother++ # for taking a shot at a small part of the underlying task in CB earlier.

I'm reckless enough to throw many hours into reading dense tomes, most of which I know in advance (based on prior experience in kind) will prove but tangential to my immediate needs; I'm flush enough to throw dollars away on books that I'll read twice, store for five years, and then give away. Somewhere, I know, will be the book that speaks directly to my needs and which I will thumb over to destruction. I may as well take oko1's advice and wave cash in the air, if that's what it takes to shake the fruit from the tree.

So, I'll offer first to the Monastery the US$100 contract to produce a recommended reading list on the topic of project file and folder management. Any Monk is welcome to submit a two- or three-line bid showing you understand what I seek. If the bid is accepted, I'll PayPal in advance, in full. I propose fulfillment in a month but I'm flexible. If the bid is rejected, I'll explain why unless you expressly request I not. The work-for-hire: the reading list; becomes my property and I will publish it here under the same terms as PerlMonks itself.

We don't need the conch anymore. We know who ought to say things.... It's time some people knew they've got to keep quiet and leave deciding things to the rest of us.

I agree that Monks seem to know more about writing Perl, in almost any imaginable scope, than any other group I've seen. I suspect I'm incompetent to judge the full extent of the group's competency. :)

That's why I'm so interested in Monks' opinions -- enough to dodge considerable opprobrium in hopes of getting a few.

We don't need the conch anymore. We know who ought to say things.... It's time some people knew they've got to keep quiet and leave deciding things to the rest of us.

The task in this node is to link to resources and cite books or articles that a medium-grade Perl newcomer might study to address a specific project management task.

The specific project management task is:

Given: A project of some defined scope and nature (e.g., a utility module or a web application); and the ongoing process of creating files within it (e.g., code and documentation); and anticipating the needs to transfer, publish, and deploy this project.

Considerations: The project is developed on a Linux system and written primarily in Perl; Git has been chosen as VCS; and Module::Build as build/test/install tool. Targets include localhost, remote web host under author's control, GitHub, and CPAN.

Primary Goal: To organize those files into a working tree by good choice of filename and by nesting them within folders (directories) and those folders possibly within subfolders, also with well-chosen names.

Secondary Goal: To identify specific strategies for dealing with specific cases where it may be unwise or inconvenient to replicate working tree structure exactly when the project is transfered, deployed, copied, or published.

Dummies of appropriate content (not content of replies but content of resources; $$stuff not $ref):

Put all tests that actually execute (passing or failing) under the top-level folder t/. You might have a test for a feature not yet implemented; put that in a subfolder t/unimplemented/ and add it to MANIFEST.SKIP. Push it to GitHub but don't release it to CPAN.

Say you have a file config.txt that contains configuration data to be read by a web script upon startup. According to the discussion given previously (on page 167), that file should be stored in remotehost's path as ~/.config/myproject/config.txt. However, you do not want to keep that file there on localhost, since that would be outside of the project's enclosing folder. So, keep the file in file/config/myproject/config.txt and, for local development, employ the Wazoo workaround. Include file/config/myproject/ in your repo and in CPAN tarball releases. Also, add a rule to your JimminyCricket file (deploy.jimminy) that will cause the file to be copied out during the build to the appropriate deployment location. See JimminyCricket docs for more info on how to construct deviant install rules.