I am right now in the situation to plan the internationalization of a django project that contains mainly legacy code. The old project itself has different applications which have a strong dependency to each other, so it is hard to separate them. Looking at the time left it is impossible at all.
The main requirements for the internationalization are:
Having separate projects for each country
Each country will later have different templates
each country will introduce new features which other countries may want to use as well
the main old codebase will still be maintained and should work with new features/changes to the country projects
Do you have any ideas/setups to deal with the old code AND starting new projects with the dependency to the old code and new features? I would like to start a discussion about this.
Start by decoupling the components where possible, and convert the legacy code to (portable) apps if not the case already, and the legacy code should not live under the main project tree.
Any new features should be well documented and decoupled apps or generic libraries themselves, even if they override/interact/depend or even monkeypatch the legacy code. You want most of your project to live outside of the main project itself, and installable via pip as if they were 3rd party apps.
The main project tree should be not much more than the project main project templates, an urls.py, settings.py, any configuration/deployment templates and a fabfile, and any core apps that will be rarely customized.
Every localized customization should just be either "customization" apps themselves, or small tweaks to main project (that should be made in a reproducible way via fab, or any provider of your choice)
Needless to say, if every team can commit to the core project, a good git/hg workflow is essential, and use a central CI server with a good test suite.
Related
I am trying to restructure a large project so that I can have one core set of code reused among a web frontend application written in flask and an automated back end that uses luigi tasks.
so I have two clients that I'd like to share code between in order to access a database and perform some automated tasks from either the web or luigi.
What is a good way to keep those three things organized and structured so that I can easily import core modules into either project.
I've had some issues getting Luigi to recognize modules that are parallel to it.
Technically, the only requirement to re-use the code is that the Python files of the shared modules ("core set of code") are found via sys.path of the executing interpreter, e.g. by adding the according directory to the PYTHONPATH environment variable. This enables you to use them as modules. However, you have to assess the changes to your project layout depending on your version control scheme and how you deploy the web application and clients. Usually, I would assume that you have to use the following rules of thumb.
Manage the shared code modules as a separate project. Especially, if the lifecycles of the depending clients and web applications are not tied together.
Treat the shared core modules as a library or framework. I should not rely on implementation details of the web application or the clients. Usually, you need to provide some entry points and configuration hooks.
Change your deployment in a way that the shared core modules are pulled as a dependency of the according client/application. There is a magnitude of possibilites depending on your setup and use case. For example, you could build pip-installable packages using setuptools.
We have few Zope&Plone projects in our company and until today I was only one single developer developing all changes throught ZMI or ZopeEdit. Our company is growing so I need to start cooperating with others developers which can help me with developing features and solving bugs in projects. This means that is no more possible to use ZMI but every developer needs to make and test own changes without affecting others work and paste own changes to production enviroment using git merge in git repo.
I need to move development to git - this means I need to start tracking all portals files and settings in git.
I think I need to move whole projects from ZODB/ZMI (including templates, scripts, sql methods, properties as portal_properties or portal_javascripts etc.) to filesystem and run git on this file system. In the next step every developer can install own pure Plone instance, pull source code and settings from git, create own branch, make changes, test, commit, push, code review ...
My question is: Is there any way to do this and start well-known rapid development process using git? Supports ZODB something like "live migration" of content/settings to/from filesystem? Is there any way to tel Zope to load some folder with content/settings from filesystem instead only from ZODB?
I know there is something called eggs, but is possible to move all types of files mentioned above to separated egg?
Thank you for your help.
The way your company was following until now was the "Old Way Way" of Plone development, but this was a deprecated and discouraged way to do.
Nowadays ZMI can still be used for "quick and dirty" fixes, but commonly this changes stored in DB must be removed (and moved to real code) as soon as possible. This was already possible on Plone 2.0!
More important: every new Plone release tend to reduce the ZMI powers (for example: until Plone 2.1 you were able to do lot of stuff from ZMI, starting from Plone 2.5 some UI elements where impossible to be modified TTW).
So: the answer to your question is "yes". Plone can (must) read code from filesystem, and this code can be stored on VCS (it can be git svn, ...).
All of those information can be found in the Plone Developer Manual.
Creating a new Plone package for modern Plone? Use mr.bob.
Automatically integrate VCS in your buildout? Use mr.developer
If you are starting today from a project you where developing through ZMI you must probably mode code from ZMI to filesystem.
This can be done manually; it's simpler as you are using Zope External Editor.
There is also a very old add-on (Plone Skin Dump) for flushing skin content to filesystem, but I fear it won't work on recent Plone, thus it was not supporting some stuff like SQL methods (if you are using them).
You can have a look at http://docs.plone.org/develop/
There you can find how to create a package (egg). Its source code can be added to git. You can checkout your git repository using mr.developer during buildout. https://pypi.python.org/pypi/mr.developer/
You can use mr.bob to create a PloneAddon. For MySQL you can use MySQL Python. Add this Packages to your Buildout in the eggs section.
Then you can write your own MySQL Statements in the Addon. I know reimplementation is expensive, but you have more control in the future.
I have core django admin project that when my customers purchase needs to be modified both in configuration and function. Each customer will have their own instance of the project installed on a different server. Currently I am using django apps to separate out the difference in clients and using settings.py to load the correct app for the correct customer.
So my questions:
Is there a industry standard/best practice/framework to customize configuration and functionality in django admin projects and distribute them?
What would be best to do is write your core project on one side, and store it in a repository (version control). Apart from that, write your sub-applications as requirements and store/track them on separate version control.
Then, to keep everything working together and keep it all integrated, what you should do is that for different functionality, write it all in the same app, but add special settings that change the app's behavior. These settings can be stored in an independent settings_local.py that is imported at the end of your settings file, making them installation-independent, and you keep in your settings.py those that are general to all installations.
In the old world I had a pretty ideal development setup going to work together with a webdesigner. Keep in mind we mostly do small/fast projects, so this is how it worked:
I have a staging site on a server (Webfaction or other)
Designer accesses that site and edits templates and assets to his satisfaction
I SSH in regularly to checkin everything into source control, update files from upstream, resolve conflicts
It works brilliantly because the designer does not need to learn git, python, package tools, syncdb, migrations etc. And there's only the one so we don't have any conflicts on staging either.
Now the problem is in the new world under Heroku, this is not possible. Or is it? In any way, I would like your advice on a development setup that caters to those who are not technical.
How about a static 'showcase' site where all possible UI elements, templates, etc are shown using dummy content. The designer can connect, edit stuff and you merge in the changes in the end. Another option would be a test server with the full application running (kind of like you did it before) but with the option to connect via FTP or whatever the designer prefers.
Why not store all of the assets on S3?
It sounds to me that they don't really need to be part of the application at all, but external resources that the application references.
I'm building a e-commerce website which consists of several domains:
www.example.com: main website which show all items
passport.example.com: this website handle everything related to users like ordering, user information management and so on
static.example.com: holding static contents
admin.example.com: for admin use
The customer ask me to build three websites(website 'static' does not required a application to handle) and put 'em into three servers. These websites need to share models and templates. Should I build three projects? Is there any better way to handle this situation in Pyramid?
Thanks.
The way I do it is I create a separate python package for my models (and you might want to make another one for your templates), and I python setup.py develop it in each project's virtualenv. Also, I usually keep all the projects under the same source control repository, to make sure there is no version problem when deploying. You could probably get the same result by using version numbers in your dependencies of the setup.py of your different projects.
If this sound new to you, you might want to read http://guide.python-distribute.org/.
Each package has it's setup.py telling the package name and version number, and also a list of dependencies.