Cinema tools local development, control and deployment

Hi all,

I'm currently trying to organise the way we develop, control and deploy our tools to the team and I'm trying to understand what would be the best solution to develop locally without conflicting with deployed libraries.
Hopefully this is something that some of you have experience, so would be awesome to hear your thoughts please.

I'm not sure if my idea is feasible, because of the way Cinema imports 3rd party modules, but hopefully we can have a workaround.
To start off my idea would be to develop within a virtual environment inside the user Cinema's preferences.
For example:

Create a virtual environment folder here
C:\Users\user_name\AppData\Roaming\MAXON\Cinema 4D R19_BFE04C39\library\scripts\virtual_envs
or
C:\Users\user_name\AppData\Roaming\MAXON\Cinema 4D R19_BFE04C39\plugins\virtual_envs

This would let me control which libraries I've install for that tool, without affecting the deployed libraries in
C:\Program Files\MAXON\Cinema 4D R19\resource\modules\python\Python.win64.framework\Lib\site-packages

Once we are happy to release the tool, we would push it as a package with other tools (including 3rd party modules) to source control it.

Would then be scheduled to deploy to the team as a package to the correct folders.
Creating a cycle by deleting the package first (if exists) and deploying the newer version.

Hopefully this makes any sense!

Thank you very much for your help and ideas! :relaxed:

Andre

Hello,

Regarding your script plugins, you can use Environment Variables like C4D_SCRIPTS_DIR (see help)

You can also use the argument g_additionalModulePath (instead of using the preferences) to add path where you store your modules so you can separate your development tools and the one for production. This one can be used as an argument for cinema4D or as a Environment variable. Of course

you can also use

About the Python librairies, you really need to have different version of your librairies ?

Cheers
Manuel

@m_magalhaes said in Cinema tools local development, control and deployment:

Hello,

Regarding your script plugins, you can use Environment Variables like C4D_SCRIPTS_DIR (see help)

Hi Manuel,

Cheers for your help!

To be honest as long as I have the development and production packages separate I'm happy.

You can also use the argument g_additionalModulePath (instead of using the preferences) to add path where you store your modules so you can separate your development tools and the one for production. This one can be used as an argument for cinema4D or as a Environment variable. Of course

Sorry don't know where to use the argument I'm afraid. Can you please clarify?
I understand what you mean now! I've checked this thread as well and makes more sense. I'm using R19 at the moment, so it seems no go after trying. Unless I'm incorrect?

you can also use

About the Python librairies, you really need to have different version of your librairies ?

Cheers
Manuel

At the moment no! But I can see it becoming a problem. Would prefer to have this sorted now, then having to fix it later.
I'm thinking using Rez to load the packages. Would that be wise?

Thanks again! :relaxed:

hello,
By the way i moved the topic to this catégorie it's more general.

About arguments, that something you can add on your shortcut for example or your arguments list on visual studio (or xcode)
Yes if you are using r19 you can use the old environment variables.C4D_PLUGINS_DIR and C4D_SCRIPTS_DIR
(there was a bug with C4D_SCRIPTS_DIR you can enter only one path, corrected with R21)
you can create those variable with a shell script that will also launch Cinema4D.

About the python librairies :

we have not too much experience on that area. I want to fully understand and be sure.

You want to have in the same cinema4D's environment several version of python librairies.
You could have something like :
for a python librairie :
version 1.2 for a tool that is already in production
version 1.4 for an update you are working on and still not released
and switching from one to another ?

Cheers
Manuel

@m_magalhaes said in Cinema tools local development, control and deployment:

hello,
By the way i moved the topic to this catégorie it's more general.

hi,

Absolutely fine! Thanks for moving it! :+1:

About arguments, that something you can add on your shortcut for example or your arguments list on visual studio (or xcode)
Yes if you are using r19 you can use the old environment variables.C4D_PLUGINS_DIR and C4D_SCRIPTS_DIR
(there was a bug with C4D_SCRIPTS_DIR you can enter only one path, corrected with R21)
you can create those variable with a shell script that will also launch Cinema4D.

Awesome! Works fine at the moment.

About the python librairies :

we have not too much experience on that area. I want to fully understand and be sure.

You want to have in the same cinema4D's environment several version of python librairies.
You could have something like :
for a python librairie :
version 1.2 for a tool that is already in production
version 1.4 for an update you are working on and still not released
and switching from one to another ?

Yes, that's about right! I'm going to try and create something that enables me to check the requirements for each package and compare it against new updates in the server and only install if not found, which hopefully will give me more control. Not sure if it will stop any issues, but it will be easier for me investigate and learn.

Started exploring Rez, but it's currently not working, already giving errors with cmake and I'm just running the example hello_world. Using Windows 7, which from what I read is not really the best for it.
If there is anyone with some solution do let me know, please. Will try and have another go.

> C:\Users\anjosa\Downloads\rez-master\rez-master\example_packages\hello_world>r
ez-build

--------------------------------------------------------------------------------

Building hello_world-1.0.0...
--------------------------------------------------------------------------------

Resolving build environment: python
resolved by anjosa@GBMUD11368, on Wed Aug 28 16:07:48 2019, using Rez v2.40.3

requested packages:
python
~platform==windows         (implicit)
~arch==AMD64               (implicit)
~os==windows-6.1.7601.SP1  (implicit)

resolved packages:
arch-AMD64               c:\users\anjosa\packages\arch\AMD64
                                    (local)
os-windows-6.1.7601.SP1  c:\users\anjosa\packages\os\windows-6.1.7601.SP1
                                    (local)
platform-windows         c:\users\anjosa\packages\platform\windows
                                    (local)
python-2.7.9             c:\users\anjosa\packages\python\2.7.9\platform-windows\
arch-AMD64\os-windows-6.1.7601.SP1  (local)

Invoking cmake build system...
Executing: c:\cmake\bin\cmake.exe -d C:\Users\anjosa\Downloads\rez-master\rez-ma
ster\example_packages\hello_world -Wno-dev -DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJE
CT=TRUE -D_ECLIPSE_VERSION=4.3 --no-warn-unused-cli -DCMAKE_INSTALL_PREFIX=c:\us
ers\anjosa\packages\hello_world\1.0.0 -DCMAKE_MODULE_PATH=%CMAKE_MODULE_PATH% -D
CMAKE_BUILD_TYPE=Release -DREZ_BUILD_TYPE=local -DREZ_BUILD_INSTALL=0 -G NMake M
akefiles
Not searching for unused variables given on the command line.
CMake Error: Could not create named generator NMake

Generators
  Visual Studio 16 2019        = Generates Visual Studio 2019 project files.
                                 Use -A option to specify architecture.
* Visual Studio 15 2017 [arch] = Generates Visual Studio 2017 project files.
                                 Optional [arch] can be "Win64" or "ARM".
  Visual Studio 14 2015 [arch] = Generates Visual Studio 2015 project files.
                                 Optional [arch] can be "Win64" or "ARM".
  Visual Studio 12 2013 [arch] = Generates Visual Studio 2013 project files.
                                 Optional [arch] can be "Win64" or "ARM".
  Visual Studio 11 2012 [arch] = Generates Visual Studio 2012 project files.
                                 Optional [arch] can be "Win64" or "ARM".
  Visual Studio 10 2010 [arch] = Generates Visual Studio 2010 project files.
                                 Optional [arch] can be "Win64" or "IA64".
  Visual Studio 9 2008 [arch]  = Generates Visual Studio 2008 project files.
                                 Optional [arch] can be "Win64" or "IA64".
  Borland Makefiles            = Generates Borland makefiles.
  NMake Makefiles              = Generates NMake makefiles.
  NMake Makefiles JOM          = Generates JOM makefiles.
  MSYS Makefiles               = Generates MSYS makefiles.
  MinGW Makefiles              = Generates a make file for use with
                                 mingw32-make.
  Unix Makefiles               = Generates standard UNIX makefiles.
  Green Hills MULTI            = Generates Green Hills MULTI files
                                 (experimental, work-in-progress).
  Ninja                        = Generates build.ninja files.
  Watcom WMake                 = Generates Watcom WMake makefiles.
  CodeBlocks - MinGW Makefiles = Generates CodeBlocks project files.
  CodeBlocks - NMake Makefiles = Generates CodeBlocks project files.
  CodeBlocks - NMake Makefiles JOM
                               = Generates CodeBlocks project files.
  CodeBlocks - Ninja           = Generates CodeBlocks project files.
  CodeBlocks - Unix Makefiles  = Generates CodeBlocks project files.
  CodeLite - MinGW Makefiles   = Generates CodeLite project files.
  CodeLite - NMake Makefiles   = Generates CodeLite project files.
  CodeLite - Ninja             = Generates CodeLite project files.
  CodeLite - Unix Makefiles    = Generates CodeLite project files.
  Sublime Text 2 - MinGW Makefiles
                               = Generates Sublime Text 2 project files.
  Sublime Text 2 - NMake Makefiles
                               = Generates Sublime Text 2 project files.
  Sublime Text 2 - Ninja       = Generates Sublime Text 2 project files.
  Sublime Text 2 - Unix Makefiles
                               = Generates Sublime Text 2 project files.
  Kate - MinGW Makefiles       = Generates Kate project files.
  Kate - NMake Makefiles       = Generates Kate project files.
  Kate - Ninja                 = Generates Kate project files.
  Kate - Unix Makefiles        = Generates Kate project files.
  Eclipse CDT4 - NMake Makefiles
                               = Generates Eclipse CDT 4.0 project files.
  Eclipse CDT4 - MinGW Makefiles
                               = Generates Eclipse CDT 4.0 project files.
  Eclipse CDT4 - Ninja         = Generates Eclipse CDT 4.0 project files.
  Eclipse CDT4 - Unix Makefiles= Generates Eclipse CDT 4.0 project files.

16:07:48 ERROR    BuildError: The cmake build system failed.

Thank you very much! :relaxed:

Hello,

I will have to ask to see if someone have experience on that. As you may know (or not) we are at few days from the release of R21. So once the release is gone we will have more room.

I'll be back once I have informations. Don't hesitate to ping us again if you don't have feedback from me.

About your issue with Rez, you should ask them, If i had the answer I would share but it's out of our scope we can't investigate this part :)

Cheers,
Manuel

@m_magalhaes said in Cinema tools local development, control and deployment:

Hello,

I will have to ask to see if someone have experience on that. As you may know (or not) we are at few days from the release of R21. So once the release is gone we will have more room.

Hi Manuel,

Thank you! looking forward to have a play with it! :relaxed:

I'll be back once I have informations. Don't hesitate to ping us again if you don't have feedback from me.

About your issue with Rez, you should ask them, If i had the answer I would share but it's out of our scope we can't investigate this part :)

Cheers,
Manuel

That's fine! I'm currently just exploring some possibilities that hopefully will be helpful to people. Because of time constraints might leave Rez for now and concentrate with something slightly simpler, less powerful. Should be good!

Thanks again! :relaxed:

And if you find something in your side, sharing that would be awesome.

@m_magalhaes said in Cinema tools local development, control and deployment:

And if you find something in your side, sharing that would be awesome.

Absolutely! :relaxed: