Developing Packages for Production Projects
Please create a development environment named main for van project (this is the production project comes with Meco™
installation) by following the steps in Creating Development Environments.
Using an Existing Package
Let's start copying the package aDisplayMessage that we created previously from this path;
/<PATH>/meco/master/developers/<USER_NAME>/development/main/aDisplayMessage
To this path.
/<PATH>/meco/van/developers/<USER_NAME>/development/main/aDisplayMessage
So now we have the same package in our development environment on van project.
Initializing a Development Environment for a Production Project
We have recently created a development environment named main for van project in previous steps. Let’s start
initializing it by typing meco command with project and development flags, like so;
# meco-init
meco -p van -de main
From this point we can do exact same things that we did in Developing Packages for the Master Project section. However, we are going to do something slightly different.
By executing the command above we initialized van project with main development environment. Please take a look at the
displayed information about the environment. You won’t be able to see 1.1.0 version of our package under master project,
even though we have released it before. This by design and if you remember packages in development environments have
priorities over those packages in project environments. Therefore, Meco™ initialized our package from our development
environment in van project. The displayed information about it looks like this;
----------------------------------------------------------------------------------------------------
DEVELOPMENT
----------------------------------------------------------------------------------------------------
aDisplayMessage > /<PATH>/meco/van/developers/<USER_NAME>/development/main/aDisplayMessage
DYLD_FALLBACK_LIBRARY_PATH : /<PATH>/meco/van/developers/<USER_NAME>/development/main/aDisplayMessage/lib/darwin
PATH : /<PATH>/meco/van/developers/<USER_NAME>/development/main/aDisplayMessage/bin/darwin
PYTHONPATH : /<PATH>/meco/van/developers/<USER_NAME>/development/main/aDisplayMessage/python
We can literally run the following command and get the same result as before.
python -c "import aDisplayMessage.displayMessage;aDisplayMessage.displayMessage.display();"
Result:
Hello from Master Project.
Even thought it worked, the displayed message itself is not accurate. Let's fix it. Open the following file in your editor.
/<PATH>/meco/van/developers/<USER_NAME>/development/main/aDisplayMessage/python/aDisplayMessage/displayMessage.py
Replace this line:
def display():
sys.stdout.write(displayProject())
with this:
def display():
sys.stdout.write(displayProjectByEnvironment())
Now, when display function is invoked, it will use the environment variable MECO_PROJECT_NAME to display the
project name.
Save the file and execute the command again.
python -c "import aDisplayMessage.displayMessage;aDisplayMessage.displayMessage.display();"
Result:
Hello from van Project
Releasing a Package for Production Projects
Change directory to the root of our package like so;
cd aDisplayMessage
Run the release command to release it.
mmecorelease-release
If you noticed, we did not get existing version error like we did before, even though we did not bumped up the version
of our package. This is because, its first time we've released this package for van project.
Let's initialize van project by itself without a development environment. Command, as you should be very familiar
with by now is;
# meco-init
meco -p van
Take a look at the displayed information for the environment. You can see that our package aDisplayMessage version
1.1.0 is still missing in the master project. This is because we have released modified version of this package for
van production project. Packages in production projects have priorities over those packages in the master project.
Therefore, Meco™ initialized our package from our van production project by ignoring the same package the master project
regardless of its version. The displayed information about it looks like this;
----------------------------------------------------------------------------------------------------
PROJECT INTERNAL
----------------------------------------------------------------------------------------------------
aDisplayMessage - 1.1.0 > /<PATH>/meco/van/internal/aDisplayMessage/1.1.0/aDisplayMessage
PYTHONPATH : /<PATH>/meco/van/internal/aDisplayMessage/1.1.0/aDisplayMessage/python
Notice the other packages, which are initialized under the master project. Since we do not have packages with same name
in van production project they are initialized directly from the master project. This is how the master projects
serves packages to all the production projects.
Re-Initializing the Development Environment
So we have a package named aDisplayMessage in the master and van projects. We saw how and why Meco™ decides to
initialize the right one. What do you think would happen if we initialized van production project with our main
development environment with it? Remember, we still have the development version of aDisplayMessage package in it.
Let's do it and see what happens.
You know the commands by now, don’t you?
# meco-init
meco -p van -de main
Take a look at the displayed information.
----------------------------------------------------------------------------------------------------
DEVELOPMENT
----------------------------------------------------------------------------------------------------
aDisplayMessage > /<PATH>/meco/van/developers/<USER_NAME>/development/main/aDisplayMessage
DYLD_FALLBACK_LIBRARY_PATH : /<PATH>/meco/van/developers/<USER_NAME>/development/main/aDisplayMessage/lib/darwin
PATH : /<PATH>/meco/van/developers/<USER_NAME>/development/main/aDisplayMessage/bin/darwin
PYTHONPATH : /<PATH>/meco/van/developers/<USER_NAME>/development/main/aDisplayMessage/python
As you may have guessed Meco™ initialized aDisplayMessage package from our development environment directly since we
wanted this environment to be initialized, while ignoring the packages with same name in the master project and van
production project environments.