Standard for directory structure

[CSDUMMI]

I know that using a single program for project management in different language projects is good and reduces the amount one needs to learn to use a new language.

But:

That's only one half of the problem with the multitude of project managers currently in use. The other half is regarding the structure of the project itself. What does a wrapper around many different project managers give me, if I have to learn many different folder structures and go back to the documentation of the project manager p wrapped around. Then could also just use that project manager instead and save myself a lot of confusion.

A Standard directory structure

Instead of using different file structures p should try to enforce one file structure for every project type in every language imaginable. This impossible! But, look at Linux File Structure, Linux has many different Distros and everyone is slightly different, but due to the FHS, many users know where to find configurations /etc or there personal stuff /home or everything else for that matter /. Some distors use only a few of those folders in FHS, but still a user can navigate through these structures without looking up the documentation of that specific distro all the time. FHS

We could do something similar, we list a few common names for folders and then make a documentation for what should be put into these.

For example

This could be such an example documentation:

• template Folder with templates for web pages or other assets, where you dynamically change values.
• static Folder with constant assets, that aren't changed during execution
• bin Folder with results from compilations
• main.* Main entry point to executable code
• index.html Main page of a website

... And so forth. This could be used as documentation and recommendation for people, that build support packages for p and make it intuitive for the users where they can find what.

[boxed]

I think this is putting the cart before the horse. For p to be used we must first adapt and respect the existing conventions. Then maybe we can have a discussion about unifying.

We could, however, declare what the directory structure should be in p and that data structure could be used by the tool and printed by a command p structure or something.

[CSDUMMI]

But how useful is p, if you still have to look at the documentation of elm/stack/lein/cargo to get known to the directory structure? I would at least introduce a documentation about what files should do what, then we can later try to enforce these, if most of the community wants these standards to apply.

And languages will want that too, once many people use their language through p.

[boxed]

It's very useful without a standard directory structure. Most languages have pretty self explanatory structures anyway so no biggie.

Let's worry about failure for now. There are tons of ways p can fail, doing too much is one way.

[CSDUMMI]

p isn't useful, if it is just a wrapper. But right, we should first get p's MVP to work.

[boxed]

I disagree. Tons of stuff are extremely useful and valuable even though they are "just" a wrapper.

Besides, we are talking about a LOT of wrapping!

[CSDUMMI]

Well, I think I need a comprehensive introduction to p.

[CSDUMMI]

I want to point at another example and a project that is kind of similar to p, though it isn't as ambitious. Haskell has essentially two project managers:

• Cabal
• Stack

Stack is comparable to p, because it is a wrapper around cabal and it's functions. Stack makes somethings easier to do, things the developers, who are experts at using cabal, deem too complex or would be better to optimize.

But what ever these experts at cabal usage don't deem too complex, they don't simplify and document. Thus anybody with less experience in cabal has to first look through the documentation of stack and then dig into cabal and their documentation to find something experts with cabal don't even think about anymore.

I think you can use p very well, because you know the project structure very well, you are an expert with the projects p supports, but do you think people that don't know the projects structure can imply it, without looking at the official documentation?

In the worst case, these users wouldn't even know what p wraps around and have to dig into the code or documentation to get to another documentation to then look for what might solve their issue.

But I think that this is a more general issue then this one was intended to be:

For what should p create documentation and when should p direct to other documentations?

[boxed]

I think the general goal is for p to do as little as possible until it becomes untenable to not do more.

I really want to first tackle ergonomics (in python this is especially needed!), then everything else.

So at first I'd like p run, p test, p build (when applicable), p install, maybe some more, work nicely for a chunk of languages and then it being easy to configure.

[boxed]

Ah, and I think p t should be short for p test (and similar) because being super short to type is a reason to use the tool.