apm init currently treats inputs containing / as a path; is this intended?

[edenfunf]

I ran into a behavior with `apm init` on Windows and wanted to check whether this is the intended design.

When I run:

```powershell
apm init 4/15

I get:

[x] Error initializing project: [WinError 3] The system cannot find the path specified: '4\\15'

If I run:

apm init 4

it creates the directory and then continues into the interactive initialization flow.

From the current implementation, it looks like project_name is passed directly into Path(project_name), so / is not being treated as a normal character in a project name. It is being interpreted as a filesystem path separator. In practice, apm init 4/15 behaves like an attempt to initialize into the path 4/15, but because parent directories are not created recursively, it fails on Windows.

I wanted to check whether this behavior is intentional. If not, it may be worth deciding which of these two directions APM should take.

Possible directions

1. Treat the argument strictly as a project name

In this model, apm init 4/15 should be rejected as invalid input with a clear error such as Invalid project name, rather than surfacing a low-level filesystem error.

2. Treat the argument as a target path

In this model, apm init 4/15 would be a supported way to initialize a project inside a nested directory. The command would create parent directories as needed and place apm.yml inside 4/15.

Right now the behavior seems to sit somewhere in between:

• the input is already being interpreted as a path
• but nested path creation is not fully supported

That makes the current UX a bit ambiguous.

I’d be interested in hearing which direction maintainers prefer:

• strict project name semantics
• explicit support for nested path initialization

If helpful, I can also turn this into an issue once the intended behavior is clear.

[danielmeppiel]

I'd go for the simplest path first, strict project name. We should add validation there.

[edenfunf]

Got it, thanks for confirming — appreciate the guidance.

I'll prepare a PR that:

• rejects inputs containing path separators (/, \)
• adds a clear validation error (e.g. "invalid project name")
• includes a test case for this scenario

I'll open it shortly.