Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prepare packaging (zest) #24

Closed
AntoineCezar opened this issue Nov 11, 2012 · 8 comments
Closed

Prepare packaging (zest) #24

AntoineCezar opened this issue Nov 11, 2012 · 8 comments

Comments

@AntoineCezar
Copy link
Contributor

Extracted from issue #17

@kiorky
Copy link
Member

kiorky commented Nov 16, 2012

related commits :
2f98d9d 03fae7d 694e173

@AntoineCezar
Copy link
Contributor Author

Great job ! I have just one concern : does the buildout flow needs to break the pyramid flow ? (I've never used buildout)

@kiorky
Copy link
Member

kiorky commented Nov 16, 2012

What are you calling pyramid flow !?

@AntoineCezar
Copy link
Contributor Author

I mean not having to learn buildout in a pyramid project.
Is there a way to keep the pyramid standard files and folder structure ?

@kiorky
Copy link
Member

kiorky commented Nov 16, 2012

The only missing files are dev.ini and prod.ini which are generated now via buildout, i readded regenerated ones in b43dd69
There is no others changes in the distribution.

@ghost
Copy link

ghost commented Nov 17, 2012

It really looks like all those buildout boilerplate files don't belong to the project's main source code repository. Seeing things like "apache" in the source code raises a clear sign that this doesn't follow the SoC principle.

Committing an empty var directory seems a bit odd. Surely this can be created when needed. This is why this practice is not supported by git, hence the .empty file hack.

Is there any added value in burying the source code under two levels of directories? I understand that creating the src subdirectory might be motivated by separating application source code from buildout boilerplate files (see my first point), but why src/convertit?

More generally speaking, what would buildout add to the project at this point? Buildout is great for managing non-Python dependencies, but if it's not used that way yet, what's the motivation for using it?

My feeling is that buildout is too intrusive to be hardcoded in the project and I don't see at this point any benefit in introducing tight coupling between a deployment tool and the application source code.

@kiorky
Copy link
Member

kiorky commented Nov 17, 2012

I ll not go in any debate just do no press the merge button if you dont understand the sense of sain commits.
Just burn your wings with some namespaces issues with top level directories in develop mode and you ll never forget to package correctly your distributions with a inner top level directory.

@kiorky
Copy link
Member

kiorky commented Nov 17, 2012

btw, i just subscribed out notifications, just speak to @leplatrem for anything else.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants